Fix first whatever can publish, deploy or push code with the least friction: accounts and tokens that hold release rights. Then fix CI, then name resolution, then update intake. The right order depends on what you build, so score each entry point by exposure and blast radius.
Why order matters
Teams usually have a long list of supply chain controls and a short list of hours. A control that blocks a rare path while a stolen token still works is effort in the wrong place.
The OWASP Top 10 CI/CD Security Risks project lists ten risk areas, including inadequate identity and access management, dependency chain abuse, poisoned pipeline execution and insufficient credential hygiene. The list is a reminder that identity and credentials sit next to pipeline design, not below it.
Score each entry point on two questions
For every entry point, ask:
- Exposure: how many people, bots or systems could trigger this path today?
- Blast radius: if it were abused, what could the attacker publish, deploy or read?
Give each a score of one to three and multiply. Work from the highest product down.
| Entry point | Exposure question | Blast radius question |
|---|---|---|
| Publishing accounts and tokens | How many accounts and stored tokens can release? | Does one token reach every package? |
| CI pipeline | Who can change workflows or open pull requests that run jobs? | Do jobs hold deploy or publish secrets? |
| Name resolution | Do any builds search more than one source for a package? | Is a private name unclaimed on a public registry? |
| Update intake | Do new releases flow in automatically? | Does a build install and run new code unattended? |
A typical order for a small software team
Most teams land on this order, but your scores should overrule it.
- Turn on two-factor authentication for every account that can publish or push to protected branches.
- Replace long-lived release tokens with short-lived ones, or at least narrow and expire them.
- Set the default pipeline token to read only and grant write per job.
- Pin package sources and commit lockfiles so a build fetches only what you reviewed.
- Add a review step for new dependencies and for changes to workflow files.
When the order changes
If you publish a widely used library, publishing accounts and release automation rise to the top, because your blast radius extends to everyone downstream. If you only consume packages and ship an internal service, name resolution and update intake matter more.
If you run self-hosted CI runners, give them early attention. GitHub's documentation notes that self-hosted runners do not guarantee ephemeral clean virtual machines and can be persistently compromised by untrusted workflow code, so they should almost never be used for public repositories.
What to record
Write the scores in a small table and date it. Review it each quarter or after any change to how you release. An out-of-date ranking is a quiet source of false comfort.
Where Safeguard fits
Asset discovery and dependency scanning in Safeguard can show you which projects consume which packages, which helps you score exposure. Policies and gates can then enforce the rules you pick. A free scan is a way to start the inventory.
Quick check
Is there one universal first fix?
Account security is the most common answer, because a taken-over account bypasses most other controls. Your own scores matter more than a generic list.
How often should I re-rank?
Review quarterly and after any change to your release process, hosting or team access.
Sources
Last reviewed: 19 October 2026.
