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.

Map source to deployment

The chain includes repository, dependencies, CI runner, base images, build, registry, signatures and deployment. Record inputs, executing identity, modification paths and generated evidence at every stage. An attack can enter through a package, maintainer account, workflow or registry.

An SBOM answers what an artefact contains but does not prove an untampered build. Provenance records who built it, where and from which inputs. You need both plus a policy that verifies them before deployment.

Using SLSA accurately

SLSA 1.2 uses tracks and levels. Build L1 requires provenance, L2 a hosted build platform and L3 a hardened build process. A higher level does not claim vulnerability-free code or a trustworthy producer; it strengthens origin and build-integrity guarantees.

Secure publication pipeline

Separate code change, approval, build and publication rights. Runners receive short-lived identity and no persistent production key. Build in a clean environment and make the signed artefact immutable. Deployment verifies signature, provenance, source and policy—not only a tag.

Workflow, lockfile, package-source and install-script changes require extra review. Triage SCA alerts using deployed version, code reachability, exposure and available remediation.

Responding to a poisoned component

Maintain a product-to-version inventory, a publication stop control and a clean-input rebuild path. Revoke trust in the affected artefact, notify consumers and preserve provenance for investigation. Exercise the process before a critical package becomes an active incident.

Sources: SLSA Specification 1.2, SLSA — About, OpenSSF Scorecard.