After a supply chain incident, fix first the things that would have shrunk this incident: short lived credentials, pinned third party actions, frozen lockfile installs, stored SBOMs for each release and log retention that covers your detection time. Then add cooldowns and tighter runner isolation. Start with what is cheap and widely effective.
Pick fixes by what failed
A review after the incident should name the gap that mattered: how it got in, how long it took to notice and how far it spread. Match each answer to a control.
Prioritised backlog
| Priority | Fix | What it limits | Source of the guidance |
|---|---|---|---|
| 1 | Short lived tokens, least privilege | Time a stolen secret is useful | GitHub hardening guide |
| 2 | Pin actions to full commit SHA | A moved tag swapping in malicious code | GitHub hardening guide |
| 3 | Frozen lockfile installs in CI | Surprise version changes | npm ci docs |
| 4 | Store an SBOM per release | Time to answer were we affected | Internal practice |
| 5 | Keep logs long enough | Unknown results | Audit log has 180 day window on GitHub |
| 6 | Ephemeral runners | Carry over between jobs | SLSA threats |
| 7 | Dependency cooldown | Fast moving malicious releases | See cooldown guide |
| 8 | Disable install scripts where possible | Install time execution | npm config docs |
Notes on the table
GitHub recommends pinning actions to a full length commit SHA, since tags can be moved or deleted if an action's repository is compromised, and notes that a workflow dependency lockfile is stronger where adopted. The npm docs say npm ci never writes to the lockfile, and exits with an error when it disagrees with package.json. npm runs lifecycle scripts by default, and setting ignore-scripts stops that, though some packages need their scripts to build.
Steps
- Turn the review findings into tickets with owners and dates.
- Do items 1 to 3 within a sprint. They are low cost.
- Schedule 4 to 6 within a quarter.
- Trial 7 and 8 on one team before rolling out, because they can slow work.
- Track completion in the same place as other risks. See the dependency cooldown guide.
Measure progress
Pick one or two measures per item, such as the share of workflows with pinned actions, the median token lifetime, and the share of releases with a stored SBOM. Review them monthly. The numbers do not need to be perfect. They show whether the controls are spreading or stalling, and they give leadership something concrete to ask about after an incident.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a gate stops a risky change at review time, which is one way to enforce items above.
Quick check
Should we do everything at once?
No. Do the cheap controls first and trial the disruptive ones.
How do we know a fix worked?
Test it. For example, attempt a lockfile change in a pull request and confirm CI fails.
Safeguard policies and gates can enforce dependency rules in pull requests. A free scan is at gold.safeguard.sh/scan.
Sources
- GitHub Docs, Security hardening for GitHub Actions
- npm Docs, npm ci
- GitHub Docs, Reviewing the audit log for your organization
- SLSA, Threats and mitigations
Last reviewed: 19 October 2026.
