Skip to main content
The --fix flag rewrites workflow YAML in place for the categories where a safe, deterministic fix exists. After applying fixes, the scanner re-runs so the final report shows only what’s left.

​
What gets fixed

​
What it won’t fix

  • The “generic var := "..."” CICD-SEC-6 pattern — matches an enclosing assignment, not just the secret value; a blind rewrite would corrupt syntax.
  • curl | sh patterns (BEST-PRAC-1). There’s no safe automatic rewrite; flagged for manual review.
  • Self-hosted runners (BEST-PRAC-3). Often intentional infra choice.

​
What you need before running

  • Network access to api.github.com for CICD-SEC-3 — the fixer hits the GitHub API to resolve each tag to a commit SHA. If resolution fails, the action is left as-is and a warning is printed to stderr.
  • Write access to the workflow files — fixes are applied in place. Commit clean first so the diff is reviewable.
--fix is not supported when scanning a remote repo with -g owner/repo. The CLI prints a warning and skips the fix step. Clone the repo yourself if you want to fix and inspect the diff.

​
Repository-configuration auto-fix (--fix-settings)

--fix rewrites workflow YAML in your working tree. --fix-settings is the GitHub-API counterpart: it remediates the repository-configuration findings (branch protection, default GITHUB_TOKEN, Dependabot, secret scanning) by hitting the GitHub API directly. It’s a separate flag because the required token scopes are wider — opt in only when you want it.

​
What --fix-settings won’t touch

​
Token requirements

The fixer uses the same --github-token (or $GITHUB_TOKEN or gh auth token) that the audit uses, but needs wider scopes for the writes:
  • administration: write — branch protection, secret scanning, Dependabot
  • actions: write — workflow permissions
If the token lacks a scope, that specific rule fails (other fixes in the same run still proceed). Errors are printed to stderr.

​
--dry-run

--dry-run short-circuits PUT/PATCH/POST before they hit GitHub but lets the GET requests through, so the printed action descriptions still reflect the real current state. Use it whenever you’re unsure.

​
Web app: open a fix PR

The web dashboard exposes the same fixers on a different surface: per-finding, click Open fix PR to have Pipefort fetch the workflow file from GitHub, run the fixer in memory, push the result to a branch named pipefort/fix/<rule>/<file>, and open a pull request for human review. Compared to the CLI’s --fix:
  • The CLI mutates files in your local working tree; the web app opens a PR. Nothing lands on your default branch until you merge it.
  • The web app uses the GitHub App installation token (see GitHub App permissions). The CLI uses whatever scopes are on the --github-token you pass.
  • Repeat clicks on the same finding converge on the same PR — the branch name is deterministic from <rule_id>/<file>. Re-running the fix after the file changed pushes an updated commit to the same branch.
  • The web app re-scans the freshly-fetched file before applying the fix. If the finding has been remediated manually since the last scan, you get a clean “already remediated — nothing to change” response instead of an empty PR.
Same eight workflow rules are covered in both places — see the “What gets fixed” table above.
1

Commit clean

--fix mutates files. Start from a clean working tree so git diff shows only the fixer’s changes.
2

Run the fixer

3

Review the diff

Especially check the SHA pinning and PPE rewrites — both involve nontrivial structural changes.
4

Commit and push

The fixer leaves a comment after each pinned SHA so reviewers can see the original tag.