Software supply chain attacks, explained

A modern application is mostly someone else’s code: libraries, frameworks, container images, tools in the CI/CD pipeline. That’s a huge productivity lever — and an equally huge attack surface. In a supply chain attack, the criminal doesn’t break into you directly; they compromise something you trust and pull in yourself.

Why it’s so effective

Trust scales both ways. If an attacker takes over a popular library or a software update, one move reaches everyone who installs it. High-profile cases show the scale: the SolarWinds incident spread through a poisoned update, and in 2024 a backdoor was discovered in the xz Utils tool (CVE-2024-3094) — carefully slipped into open-source code by a “trusted” contributor, one step from shipping in Linux distributions.

The most common vectors

• Typosquatting and malicious packages in registries like npm, PyPI or RubyGems — a name deceptively similar to a popular library.
• Maintainer account takeover and publishing a malicious version of a trusted package.
• Transitive dependencies — the flaw isn’t in your library but in its dependency, one you didn’t know existed.
• CI/CD pipeline compromise — injecting code at build time so the artefact looks legitimate.

How to limit the risk

You can’t give up third-party code, but you can manage it:

• Dependency inventory (SBOM). You need to know what you’re actually building — a full list of components with versions is the precondition for reacting when the next CVE lands. We cover this in our piece on vulnerability prioritisation.
• Version pinning and integrity verification (lockfiles, checksums, signatures). Build from frozen, vetted versions, not “always latest”.
• Dependency scanning (SCA) wired into the pipeline, with alerts for known vulnerabilities.
• Reducing trust in CI/CD — least privilege for runners, build isolation, control over who and what can publish.
• Caution with new packages — treat freshly created, low-popularity libraries with reserve.

The defender’s perspective

A supply chain attack is a reminder that security doesn’t end at the edge of your code. The “we trust it because it’s a popular library” model is as unreliable as “we trust it because it’s a known number” in phone scams. The answer is visibility (knowing what you have), dependency hygiene and reducing trust wherever someone else’s code enters your system. If you’d like to review your application’s supply chain, get in touch.

Sources and further reading: CISA — Software Supply Chain, OpenSSF.