What is a software supply chain attack?

A software supply chain attack compromises a target through the software it depends on and the systems that build and deliver it, rather than by attacking the target head-on. Instead of breaching your perimeter, the attacker poisons something you will willingly pull in: a library you depend on, a build tool you run, an image you deploy. Your own trusted automation does the rest.

Why they work

Two properties make this class uniquely powerful.

Leverage. Compromising one widely-used dependency or build tool reaches every downstream consumer at once. The effort is spent once, upstream; the payoff multiplies across thousands of victims who never interacted with the attacker.

Trust. The malicious code arrives through channels organizations already trust - a version bump, a signed release, a routine CI run. The defenses tuned to reject foreign input wave through expected input, and the compromise rides in on legitimacy.

The shapes they take

Mapping real incidents yields a recurring set of techniques, frequently chained:

• Poisoned dependencies: a malicious package, a hijacked-maintainer account pushing a bad release, or naming tricks like typosquatting and dependency confusion that get a malicious package installed in place of the intended one.
• Compromised build systems: the attacker gets into the pipeline and injects malicious code into otherwise-legitimate, properly-signed releases - the hardest variant to detect, because the output looks authentic.
• Tampered artifacts: a malicious layer in a container image or a modified binary shipped from a registry.
• Stolen pipeline credentials: secrets lifted from CI used to publish malicious releases or move laterally.

Why single tools miss them

The defining reason supply chain attacks succeed operationally is that they cross layers that separate tools watch in isolation. The dependency scanner sees packages but not the build system; the container scanner sees images but not git history; the secrets scanner sees credentials but not which service exposes them. An attacker moving dependency → build access → stolen token → lateral movement appears in each console as a separate, medium-priority curiosity. The pattern that would scream compromise exists only in the union of the views - and usually nobody is looking at the union.

What actually defends

There is no silver bullet, and credible tooling says so. What works is layered coverage plus correlation:

• Cover every layer - dependencies, secrets across history, container images, and build and infrastructure configuration - so there are fewer usable seams.
• Correlate across layers, so the vulnerable dependency, the leaked credential, and the misconfigured runtime on the same service are seen as one picture rather than three curiosities.
• Keep an inventory that answers the aftermath. When the next upstream compromise is disclosed, which of our shipped builds contain the affected component should be a query answered in minutes, not an archaeology project.

The realistic promise is a smaller blast radius and a faster answer, which is exactly what full-surface coverage feeding one correlated queue is built to deliver.