Skip to main content
Some Pipefort rules don’t apply to every team. A research-only org might intentionally skip BEST-PRAC-2: Job timeout not configured. A monorepo team might want CICD-SEC-1: Default branch does not require signed commits muted on prototype repos but enforced elsewhere. The Rule policy page lets you turn any individual rule on or off, with two layers:
  • Org default — applies to every repository that inherits.
  • Per-repository override — a specific repo bucks the org default (tri-state: inherit, enabled, or disabled).
Changes affect future scans only. Existing findings are never modified or deleted retroactively. After a toggle, the SPA shows a banner with a one-click “Re-scan” button.

​
The two panes

Open Rule policy in the left sidebar (route: /rules). The rule list on the left is grouped by family — CI/CD Top 10, Best practice, SLSA — with each rule’s id, a severity dot, and how many findings it produced in the latest scans. A disabled rule is dimmed. The search box filters by id, title or category. Selecting a rule opens its detail pane, which is where both layers are resolved.

​
Org default

One control: Enabled or Disabled, applying to every repository that inherits.
On or off is the whole policy today. A per-rule severity, a confidence floor and an auto-fix mode would each need a column that rule_settings does not have — the page says so rather than showing controls that could not take effect.

​
Per-repository override

One row per repository, with four things about the selected rule: Effective is the column that matters. A rule can be on org-wide and off in the one repository you care about, and no single toggle can tell you that.

​
Staged changes

Edits are staged, not saved on click. The footer counts what is pending and holds it until you press Apply; Discard throws the pending set away. This is deliberate. A policy change that lands repository-by-repository as you click leaves the organization half-applied if you stop halfway or lose the tab. Staging also means the table shows what will be true once applied, not a mix of saved and unsaved values. Apply sends the whole pending set as one request (PUT /api/rule-overrides:batch), which the API applies in a single transaction. So there is no “partway”: either every staged change lands or none does, and a failed apply leaves the entire set staged with the message Nothing was changed. A retry is the same request rather than a reconstruction of whichever half did not take.
Last changed records the actor and the date. The schema stores no reason for a policy edit and there is no separate audit history, so the column stops after the date rather than implying a paper trail that does not exist.
After a successful apply the footer offers a one-click re-scan across your repositories, because policy affects future scans only.

​
How filtering happens

Filtering runs at scan time, before results are saved. When a scan runs, your global settings and this repo’s overrides are merged (override wins), and findings whose rule is disabled are dropped before anything is persisted. As a result:
  • Severity tiles, trend charts, and the per-repo finding list are all consistent — they read the same filtered findings.
  • Old scans are unaffected. A finding logged before you disabled a rule stays in your scan history.
This composes with the existing --ruleset choice (all vs owasp): the per-rule filter runs first, then the ruleset filter. You can disable a CICD-SEC-* rule globally and still pick owasp — the rule stays disabled.

​
Interaction with an in-repo .pipefort.yml

A repository can also ship a .pipefort.yml. On the web, your org’s rule settings are authoritative: a repo config may only further restrict — it can disable a rule, downgrade a severity, or add per-file ignores, but it can never re-enable a rule your organization turned off. A repository write must not override an org security decision. Inline # pipefort: ignore comments are always honored (they’re applied inside the scan engine), which is the recommended way to silence a single expected finding.

​
What if a new rule ships?

New rules are default-enabled for every user — you have no saved preference for them yet, so they start “enabled”. Open /rules to disable any you don’t want.

​
Caveats

  • Rule IDs are stable. The doc slugs under /rules/<id> are the canonical identifiers and are unlikely to change.
  • This is a web-app-only feature. The CLI still uses --ruleset all|owasp for filtering — saved preferences are specific to the dashboard.
  • Overrides are stored per repository, so the per-rule table costs one request per connected repository to build. That is fine at current scale; a very large organization would want a per-rule endpoint instead.
  • SYSTEM / INFO notices (parse errors, “settings audit skipped” notices, rule-settings load failures) are never toggleable — they always pass.

Rules overview

The full catalog of checks across both surfaces.

API reference

Programmatic access to the rule-settings endpoints.