Software Supply Chain Security: What SolarWinds Taught Us and What We've Done Since

The SolarWinds attack of 2020 was a watershed moment. Attackers compromised the build pipeline of a widely-used IT monitoring product, inserting malicious code into signed, legitimate software updates. 18,000 organizations installed the compromised update; hundreds were subsequently breached.

Why Supply Chain Attacks Are Effective

Every piece of software your organization runs has a chain of trust behind it: the vendor’s code, their dependencies, their build systems, their signing keys, their update mechanisms. Traditional security controls don’t catch attacks delivered through trusted software channels.

The SBOM Movement

A Software Bill of Materials (SBOM) is a formal record of the components, libraries, and dependencies in a piece of software. The US government now requires SBOMs for software sold to federal agencies. The EU Cyber Resilience Act has similar requirements.

The value: when a critical vulnerability in a dependency (log4j was the canonical example) is disclosed, organizations with SBOMs can immediately identify which of their software uses that dependency. SBOM generation is increasingly automated: Syft, FOSSA, and Anchore can generate SBOMs from container images and repositories.

Practical Controls

Signed commits and builds: Requiring developer commit signing and signed build artifacts (Sigstore/cosign) creates an audit trail that can detect pipeline tampering.

Dependency pinning: Pinning exact versions of dependencies prevents unexpected dependency changes.

Binary provenance verification: SLSA (Supply Chain Levels for Software Artifacts) provides a framework for verifying that the software you’re running was built from a specific commit.

Hermetic builds: Build environments that cannot make network calls during the build process prevent dependency confusion attacks.