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.

Why Dependency Confusion Attacks Exploit a Structural Weakness

Dependency confusion attacks — where an attacker publishes a malicious package to a public registry using the same name as an organization’s internal private package, tricking misconfigured build systems into pulling the malicious public version instead of the legitimate internal one — exploit a structural ambiguity in how many package managers resolve naming conflicts between public and private registries. This attack class became widely known following high-profile research demonstrating successful compromises across major technology companies, and defending against it requires explicit namespace reservation on public registries even for packages never intended for public use, combined with build system configuration that unambiguously prioritizes private registry sources over public ones rather than relying on default resolution behavior that may favor whichever registry responds first.

The Open Source Maintainer Burnout Risk as a Security Issue

A structural security risk in the broader software supply chain that receives less attention than technical controls is the sustainability of open source maintainership itself. Critical infrastructure packages are frequently maintained by small numbers of volunteer maintainers, sometimes a single individual, creating both availability risk if that maintainer becomes unavailable and a genuine security risk if a burned-out or under-resourced maintainer is more susceptible to social engineering attempts to gain commit access, a pattern that has been documented in real supply chain compromise incidents. Organizations with significant dependency on specific open source projects increasingly recognize sponsoring critical maintainers financially as a legitimate security investment, not just a goodwill gesture, since a well-resourced maintainer is better positioned to maintain rigorous security practices than an unpaid volunteer managing the project alongside a full-time job.

Building Internal Capability for Rapid Dependency Response

When a critical vulnerability in a widely-used dependency is disclosed, the organizations that respond fastest and most effectively share a common characteristic: they have pre-built internal tooling and process for rapid dependency impact assessment, rather than scrambling to build this capability reactively during the incident itself. This means maintaining current SBOMs as standard practice rather than generating them only when needed, having clear ownership for emergency dependency patching across the organization’s services, and running periodic drills specifically simulating a critical dependency vulnerability disclosure to validate that the response process actually works under realistic time pressure rather than just existing as untested documentation.

This article is part of our ongoing coverage of Cybersecurity. For related reading, see Kubernetes security hardening and cloud misconfiguration risks.