Treat your CI workflows as production code. Pin third-party actions to a full commit SHA, give the workflow token the least permissions it needs, restrict who can change workflow files, and protect the branches that trigger deploys. These steps make your release path predictable and easy to evidence for an auditor.
Why CI is in scope
A SOC 2 auditor looking at change management wants to know how code gets from a developer to production and who can alter that path. In many startups the path is a workflow file. Whoever can edit it can change what ships, and every action it calls runs with access to your repository.
GitHub's hardening guide is blunt about the stakes: a compromised action in a workflow can access all secrets configured on the repository and may be able to use the GITHUB_TOKEN to write to the repository.
Five changes, in order of payoff
- Pin third-party actions by SHA. GitHub says pinning to a full-length commit SHA mitigates the risk of a backdoored action, because an attacker would need to produce a SHA-1 collision for a valid Git object. It also notes that tags can be moved or deleted if the action's repository is compromised. GitHub additionally describes workflow dependency lockfiles as the strongest option for repositories that can adopt them.
- Cut token permissions. Set the default for GITHUB_TOKEN to read only and grant write access per job. GitHub advises granting the minimum required permissions.
- Limit secret exposure. Any user with write access to a repository can read its secrets, per GitHub's guide, so keep deploy credentials in environments with required reviewers where you can.
- Protect workflow files. Use code owners or review rules so a change to the pipeline gets a second pair of eyes.
- Mind self-hosted runners. GitHub warns that workflows on self-hosted runners are not isolated, so separate runner groups by trust level.
Keep the pins fresh
A pinned SHA never updates itself. Use an update tool to open pull requests when a new release appears, and review the diff of the action, not only the version number. Without this step, pinning turns into stale CI full of known bugs.
What the auditor will want to see
| Question | Evidence |
|---|---|
| Who can change the pipeline? | Branch rules and code owner file |
| Can one person deploy alone? | Required reviews on the release branch |
| How are third party actions controlled? | Workflow files showing SHA pins |
| What can the pipeline do? | Token permission settings per workflow |
Export these with dates. Settings change over time, and a Type 2 window covers months.
A small example of the reasoning
If your deploy job uses a community action tagged v3 and the author's account is compromised, the tag can point to new code overnight. Your next deploy runs it with your cloud credentials. A SHA pin means that same deploy keeps running the code you reviewed.
Try it yourself
Open the demo and see how a pull request gate evaluates changes before merge. Note where a failing check blocks the path.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's policies, gates and guardrails can enforce pull request checks, and its SBOM and dependency scanning cover the packages your builds pull in. Free scan: https://gold.safeguard.sh/scan.
Quick check
Is a version tag good enough for an action?
Only if you trust the author, and even then tags can move. A full commit SHA is safer.
Do self-hosted runners change the picture?
Yes. They are not isolated by default, so group them by trust level and limit which repositories can use them.
Sources
Last reviewed: 19 October 2026.
