Software supply chain threats are ways an attacker changes what you ship by tampering with something upstream: the source, the build, a dependency or the registry that serves it. The SLSA specification lists eight integrity threats along that path. Each has a matching control, and most teams cover some links and miss others.
How is the chain laid out?
SLSA, the Supply chain Levels for Software Artifacts specification, walks the path from a developer's commit to the consumer's install. Its threats overview names these integrity threats:
- A. Submit unauthorized change. Someone with repository access pushes a change the producer did not intend.
- B. Compromise source repo. An attacker breaks into the code host and injects commits.
- C. Build from modified source. The build uses files that do not match source control.
- D. Use compromised dependency. A dependency has been tampered with and the product inherits the risk.
- E. Compromise build process. The attacker takes over the build platform.
- F. Upload modified package. A malicious artifact is uploaded, bypassing the expected build.
- G. Compromise package registry. A registry or mirror serves malicious packages.
- H. Use compromised package. A consumer installs a malicious package, for example one with a name close to a legitimate one.
It also lists an availability threat: a dependency being removed or becoming unreachable.
What defends each link?
Source (A, B). Branch protection, mandatory review by a second person, signed commits, and strong sign in with multi factor authentication for every account with write access.
Build (C, E). Build on a hosted, isolated platform from a clean checkout, record which source and which inputs produced each artifact, and limit who can change the build definition. Provenance, a signed statement about how an artifact was made, lets a consumer check that.
Dependencies (D). Know what you depend on. Keep an inventory, pin versions, review new additions and watch for advisories. NIST SP 800-161 Rev. 1 treats this as cybersecurity supply chain risk management, covering products that may contain malicious functionality, be counterfeit or be weak through poor development practice, and it notes that risk grows when an organization has limited visibility into how what it buys is built.
Registries and packages (F, G, H). Install from a controlled proxy or mirror, verify package integrity, and watch for lookalike names. Treat install scripts as code execution.
Availability. Cache the artifacts your builds need so a removed package does not stop a release.
Where does the secure development framework fit?
NIST SP 800-218, the Secure Software Development Framework, is a set of high level practices that fit into any development life cycle, meant to reduce vulnerabilities in released software and give buyers and suppliers a shared vocabulary. SLSA gives you the detailed threat map. SSDF gives you the process language you can show in a procurement review.
Constructed example: two links, one release
A small team protects its main branch with required review, which closes threat A. But its pipeline fetches a helper tool with a floating version at build time. An attacker publishes a tampered version of that tool, and the next build includes it. The review process worked and the release was still compromised, because threat D was open. The fix is to pin that version, verify its checksum and put the tool in the inventory.
The scenario is invented. It shows why a single strong control does not make a chain secure.
What can tooling do?
Dependency scanning and a software bill of materials cover the D link. Safeguard's dependency scanning, policies and gates can block a merge when a package fails your rules, and the Gold free scan at gold.safeguard.sh/scan lets you check up to 100 dependencies. Controls for source and build live in your code host and CI settings, so audit those directly.
How to check or apply this
- Draw your own chain from commit to production and mark each of the eight threats against it.
- Enforce review, branch protection and multi factor authentication on source.
- Build in an isolated, ephemeral environment and keep build logs.
- Pin dependencies and tools by version and checksum.
- Generate and store an SBOM for each release.
- Route installs through a proxy you control.
- Practice a response: how would you find every build that used a bad package?
Quick check
Is a vulnerable dependency the same as a compromised dependency?
No. A vulnerable one has an honest flaw. A compromised one has been deliberately tampered with. Both need an inventory to find, but the response differs.
Which link should I fix first?
Start with the one you cannot currently see. For most teams that is the dependency inventory, because every other check needs it.
Sources
- SLSA v1.0, Threats overview
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
