The SolarWinds compromise in 2020 was treated as a wake-up call. The XZ Utils backdoor discovered in 2024 confirmed that the software supply chain attack vector had not been adequately addressed. The pattern in both cases is the same: rather than attacking the target organization directly, the attacker compromises a trusted third-party component in the target’s software supply chain and uses that compromise to reach hundreds or thousands of downstream organizations simultaneously.

The supply chain attack is effective precisely because the security controls organizations invest in — perimeter firewalls, endpoint detection, identity and access management — are designed to detect hostile code entering from outside the trust boundary. A build pipeline installing a compromised dependency is inside the trust boundary by definition. The code arrives signed, from a known source, through an authorized channel. The security controls see a legitimate installation and do nothing.

The Scale of the Dependency Problem

A medium-complexity modern software application has hundreds of direct and transitive dependencies. A Node.js web application with 30 explicitly declared packages in its package.json may have 900 transitive dependencies — packages that the explicitly declared packages depend on, and packages that those depend on. The developer who wrote the application has read zero of those 870 transitive dependencies’ source code. They cannot. There is not enough time.

The XZ Utils backdoor was inserted through a social engineering attack on a volunteer maintainer of an obscure compression library used as a transitive dependency by OpenSSH implementations on several Linux distributions. The attacker spent two years building trust in the project as a contributor before inserting the backdoor. It was discovered by accident — a developer noticed anomalous CPU usage in a benchmark test. Automated security tooling did not flag it.

The attack surface is not merely large. It is unmappable at human scale.

SBOM: Necessary But Not Sufficient

The Software Bill of Materials — SBOM — is the regulatory and industry response to the supply chain opacity problem. An SBOM is a machine-readable inventory of all software components in an application: direct dependencies, transitive dependencies, version numbers, license information, and provenance data. The U.S. Executive Order on Improving the Nation’s Cybersecurity (EO 14028) mandated SBOM production for software sold to the federal government. Several EU regulations have followed with similar requirements.

SBOMs are necessary because you cannot secure what you cannot see. Knowing that your application includes a specific version of Log4j is the prerequisite to patching it when a vulnerability is discovered. Organizations that maintain current SBOMs responded to Log4Shell in hours. Those that did not spent days or weeks inventorying their exposure.

SBOMs are not sufficient because the attack vectors they protect against are known vulnerabilities — software components with published CVEs that can be matched against the SBOM component list. The XZ Utils backdoor was not a known vulnerability. It was an unknown backdoor in software that would have appeared clean in any SBOM scan. Provenance integrity — knowing not just what software you are running but whether that software matches the source code it claims to have been built from — requires additional tooling.

Sigstore and Build Provenance

Sigstore is an open-source project — hosted by the Linux Foundation, backed by Google, Red Hat, and Purdue University — that provides cryptographic signing for software artifacts and build provenance attestation. When a developer publishes a package signed with Sigstore, they create a tamper-evident record linking the published artifact to the source code commit it was built from, the build environment that built it, and the identity of the publisher.

The Python Package Index (PyPI), npm, and Maven Central have all integrated Sigstore-based signing. A consumer of a Sigstore-signed package can verify that the package they downloaded matches the source code in the repository, was built in the claimed build environment, and was signed by the claimed publisher identity. Inserting a backdoor at the build stage or during package distribution breaks the attestation and is detectable.

Sigstore is the most concrete technical response to the XZ Utils class of attack. Adoption is growing but not yet universal. The packages most at risk — small, volunteer-maintained packages with wide transitive dependency reach — are precisely the ones least likely to have implemented Sigstore signing.

The Organizational Response

Technical controls address part of the problem. The other part is organizational: which third-party dependencies is an organization willing to accept, and on what basis? Dependency hygiene — removing unused dependencies, pinning dependency versions, preferring well-maintained packages with active security response processes over abandoned packages — reduces attack surface even without solving the fundamental verification problem.

Vendor security assessments are evolving to include software supply chain questions: Does the vendor maintain a current SBOM? Do they sign their build artifacts? Do they have a documented process for responding to supply chain compromises in their own dependencies? These questions were not standard practice two years ago. They are becoming so.