Most software supply chain attacks start at one of five entry points: a stolen credential, a taken-over maintainer account, an abused CI pipeline, a package name trick such as dependency confusion, or a poisoned update. The attacker rarely breaks your code. They get into something your code already trusts.
What "supply chain attack" means here
A software supply chain attack is an attack that reaches you through something you consume or build with, rather than through your own application. That includes open source packages, build systems, update channels and the accounts that publish to them.
The SLSA project describes attacks that can occur "at every link in a typical software supply chain", from the source repository through the build to the package registry and the people who use the package. That is a useful way to read the list below: each entry point sits at a different link.
The five usual entry points
| Entry point | What the attacker gets | Where it happens |
|---|---|---|
| Credential theft | A token or password that can publish or push | Developer laptop, CI logs, leaked config |
| Maintainer takeover | Legitimate publishing rights to a package | Registry or email account |
| CI abuse | Code running with your pipeline secrets | Workflow files, pull requests, third party actions |
| Name tricks | Your build fetches the attacker's package | Dependency resolution |
| Poisoned update | Malicious code delivered as a normal upgrade | Registry, mirror or update channel |
These overlap. A stolen token (row one) is often how a takeover (row two) happens, and a hijacked package is how a poisoned update (row five) reaches you. Still, naming the first move helps, because the first move decides which control would have stopped it.
Why attackers pick these doors
Attackers prefer the cheapest path to many victims. One maintainer account may sit behind thousands of downstream builds. One CI secret may unlock a publishing step. One mistyped or ambiguous name may be pulled automatically by every install that has no pinned source.
The common thread is trust that nobody checks. A build trusts the registry. The registry trusts a token. The token trusts whoever holds it. Break the weakest link and the rest behaves normally, which is why these attacks can look like routine updates for a while.
A first pass at prevention
You can cut exposure at each entry point with a short list.
- Credentials: prefer short-lived credentials over long-lived tokens, and give each one the narrowest scope that works.
- Maintainer accounts: require two-factor authentication, preferably with a security key or passkey, on every account that can publish.
- CI: treat pull request text and branch names as untrusted, limit the permissions of the pipeline token, and review changes to workflow files.
- Name tricks: pin your package sources, use a lockfile and make private names unclaimable on public registries.
- Updates: review what changed, and consider waiting a short time before adopting a brand new release.
Each item has its own deeper write-up. The point of this list is the mapping: one control family per entry point.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many direct and transitive packages one project pulls in, then ask how many of their publishers you could name.
Where Safeguard fits
You cannot defend an entry point you cannot see. Safeguard's SBOM and dependency scanning builds an inventory of what you consume, and policies and gates can stop a risky change at the pull request. You can try a free scan to see your own dependency list.
Quick check
Is a supply chain attack the same as a data breach?
No. A supply chain attack describes how the attacker got in, through something you trust or consume. A data breach describes the outcome, exposed data. One can lead to the other.
Which entry point should a small team fix first?
Start with accounts and credentials, because one stolen token or one account without two-factor authentication can bypass every other control.
Sources
Last reviewed: 19 October 2026.
