Software Supply Chain Attack
Compromising software by compromising something it trusts, rather than attacking it directly.
What is a software supply chain attack?
A software supply chain attack compromises something a target trusts, rather than the target itself. Instead of finding a flaw in your application, the attacker finds a flaw in a package it depends on, the CI system that builds it, the registry it publishes to, or the update channel it ships through — and inherits your users as a side effect.
The economics are what make it the dominant pattern. Compromising one popular package reaches every organisation that installs it. The 2020 SolarWinds intrusion reached roughly eighteen thousand organisations through a single signed update; the maintainer-account takeovers that hit npm regularly reach millions of installs in the hours before anyone notices.
How it works
The patterns differ, but each one substitutes a trusted link:
- 01
Compromise a dependency
Take over a maintainer account, buy an abandoned package, or submit a malicious contribution. The payload ships in the next release to everyone who has a version range that accepts it.
- 02
Exploit resolution rules
Dependency confusion publishes a public package with an internal name so the resolver prefers it, and typosquatting registers names one keystroke from a popular one.
- 03
Compromise the build
The source stays clean and the artifact does not. An attacker with access to the CI system injects at build time, which is invisible to anyone reading the repository.
- 04
Compromise the update channel
Sign the malicious artifact with the vendor's real key, and every verification downstream passes. This is what makes SolarWinds the reference case.
Why it matters
Every conventional control assumes the code you run is the code you chose. A supply chain attack breaks that assumption upstream of the control, which is why perimeter defences, code review and even signature verification can all be operating correctly while the attack succeeds.
It has also become the regulated case. US Executive Order 14028, the EU Cyber Resilience Act and SLSA all exist because this attack class defeated the previous generation of assurance. Producing an SBOM and provenance is now a procurement requirement, not a maturity goal.
The defence is not detection of the malicious code — it is usually indistinguishable from legitimate code — but verification of the chain: knowing exactly what is in the artifact, where each piece came from, and that the build that produced it is the build you expected.
What defends against it
A complete inventory
An SBOM per build is what turns "are we affected" from an investigation into a query.
Build provenance
SLSA provenance attests which source, which builder and which parameters produced an artifact, so a build-time injection has nowhere to hide.
Signing and transparency
Sigstore and Cosign make signatures verifiable and publicly logged, so a key misuse is discoverable after the fact.
Resolution hygiene
Scoped registries and pinned lockfiles remove the ambiguity that dependency confusion depends on.
Admission-time verification
An admission controller that rejects unsigned or unattested images is the last place the chain can be checked before it runs.
How Safeguard uses it
Safeguard treats the chain as the unit of assurance: inventory through SBOM Studio, provenance and signature verification through eSSCM, and enforcement at admission. See the supply-chain compliance and maintainer-takeover detection workflows.
Verify the chain, not just the artifact.
Safeguard inventories every component, checks provenance and signatures, and blocks what cannot be attested.
Self-healing security runs on Safeguard.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.