Configuration file

Ship scan preferences and suppressions in a .pipefort.yml alongside your code.

A repository can carry its own scan configuration in a .pipefort.yml at the root (or .github/pipefort.yml). It is the CLI-friendly counterpart to the web app’s rule settings: no external state, versioned with your code, and honored by every pipefort run. This is the direct analog of zizmor’s zizmor.yml.

The CLI discovers it automatically in the scan root. Point at a specific file with --config <path>, or ignore any config for a run with --no-config.

Schema

# .pipefort.yml — every field is optional
ruleset: owasp            # default for -r (all | owasp | slsa | slsa-build-l2 | …)
min-confidence: medium    # default for --min-confidence (HIGH | MEDIUM | LOW)
persona: regular          # default for --persona (regular | pedantic | auditor)

rules:
  cicd-sec-3-unpinned-action:
    severity: LOW          # downgrade this rule's findings
  best-prac-2-missing-timeout:
    enabled: false         # turn the rule off entirely
  cicd-sec-4-ppe-shell-injection:
    ignore:
      - file: ".github/workflows/release.yml"   # glob, repo-relative
        lines: [42]                             # optional; omit to ignore the whole file

forbidden-uses:            # action allow/deny policy (see cicd-sec-5-forbidden-uses)
  deny: ["someorg/*"]

Precedence

• CLI flags win over the config. An explicit -r, --persona, or --min-confidence overrides the file’s ruleset / persona / min-confidence; otherwise the file value applies, otherwise the flag’s default.
• On the web, the org’s rule settings are authoritative. A repo’s .pipefort.yml can only further restrict — it can disable a rule, tune a severity, or add ignores, but it can never re-enable a rule your organization turned off. A repository write must not override an org security decision. (Severity tuning and ignores are honored because they’re noise-control, not policy.)

Inline suppression comments

For one-off exceptions you don’t want to centralize, drop a comment right where the finding is — on the same line, or the line above:

      - uses: acme/thing@v1  # pipefort: ignore[cicd-sec-3-unpinned-action]

      # pipefort: ignore[cicd-sec-4-ppe-shell-injection]
      - run: echo "${{ github.event.issue.title }}"

A bare # pipefort: ignore (no brackets) suppresses every rule at that location; brackets scope it to specific rule IDs (comma-separated). A trailing comment only affects its own line; a standalone comment line affects the line below it. Inline ignores work in both GitHub Actions and GitLab CI files and are honored by the CLI and the web scanner (they’re applied inside the scan engine, so every surface inherits them).

Parse errors (SYSTEM findings) can never be silenced by an ignore comment.

Acknowledgment comments

One rule carries a directive of its own, because “do not tell me about this” and “this is handled” are different claims and should read differently in a diff.

# pipefort: egress-restricted        # column 0: covers every job in the file
on: push
jobs:
  # pipefort: egress-restricted      # indented: covers just this job
  deploy:
    runs-on: self-hosted

# pipefort: egress-restricted resolves cicd-sec-8-selfhosted-egress, which flags a sensitive job on a self-hosted runner with no declared egress policy. Egress control usually lives in runner infrastructure — a firewall, a network policy, a proxy — that the scanner cannot see, so this is how you put that fact on the record. Nesting is the scope: an unindented directive covers the file, one placed above a job covers that job. It works on GitHub Actions and GitLab CI alike.

# pipefort: ignore[cicd-sec-8-selfhosted-egress] still works and does the same job; the dedicated directive just says why.