Treat a change to CI configuration as a change to what runs with your secrets. Check the trigger, the permissions, any secrets it touches, any new third-party action and how it is pinned, any untrusted input used in a script, and what code is checked out. Require a code owner to approve these files.
Why these files need a different review
OWASP calls the underlying risk poisoned pipeline execution. An attacker who can change pipeline files, or files the pipeline runs, can make the build execute their commands with the pipeline's identity and permissions, which often include secrets and deploy access. A normal code review misses it when reviewers read workflow changes as plumbing.
The checklist
| Check | What to look for | Source of the rule |
|---|---|---|
| Trigger | New triggers such as pull_request_target or workflow_run | GitHub: these must not check out untrusted code |
| Permissions | Added write permissions on the token | GitHub: grant the minimum, default read-only |
| Secrets | New secret references, or secrets passed to new steps | GitHub: environment secrets behind reviewers |
| Third-party actions | New action, unpinned or pinned to a tag | GitHub: pin to a full commit SHA |
| Inline expressions | Untrusted values placed directly in a script | GitHub: pass through an intermediate environment variable |
| Checkout | A ref from the pull request in a privileged job | GitHub and OWASP |
| Runner | Change of runner label, especially to self-hosted | GitHub: avoid self-hosted for public repos |
| Referenced files | Edits to a Makefile or scripts that the pipeline calls | OWASP indirect poisoned pipeline execution |
Process steps
- Route by path. Use a code owners rule on the workflows directory and any build scripts, so the right people must approve.
- Read the diff first, then the run. Do not approve based on a green check, since the workflow under review may be the thing that is wrong.
- Ask what the change can reach. List the secrets, tokens and environments the job can use after the change.
- Verify pins. For a new action, confirm the SHA belongs to the action's own repository, not a fork, as GitHub advises.
- Check indirect edits. A harmless looking change to a script called from a trusted pipeline is the same risk.
A small example of what to flag
Putting an issue title or pull request title straight into a run step is script injection. GitHub's advice is to set the expression value in an environment variable and read the variable in the script.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how automated gates complement human review of risky files.
Quick check
Who should own the workflow files?
A small security or platform group, via a code owners entry, so changes do not merge with a single casual approval.
Is it enough to run the new workflow on the pull request?
No. Running it may be exactly what executes the attacker's change. Review before triggering where secrets are in reach.
Safeguard enforces policies and gates on pull requests and scans dependencies, which complements review of pipeline files. Try the free scan.
Sources
Last reviewed: 19 October 2026.
