Software Supply Chain Attacks Are Doubling Every Year — Here Is How SBOMs Change the Equation

The Accelerating Threat

Software supply chain attacks exploit a fundamental property of modern software: the code you ship is mostly code you did not write. When attackers compromise an upstream component — an open source library, a build tool, a software update mechanism — they gain access to every downstream consumer of that component. One successful compromise can reach millions of systems.

The scale of this problem has grown dramatically. Sonatype's State of the Software Supply Chain report documents supply chain attacks more than doubling year over year since 2020. In 2024, 65% of organizations reported experiencing a supply chain attack — up from 41% in 2022. The attacks are not getting simpler; they are getting more sophisticated, more patient, and more targeted.

The Defining Incidents: A Timeline

SolarWinds (December 2020)

The SolarWinds attack became the defining case study for software supply chain risk at the nation-state level. Attackers — later attributed to Russian intelligence (SVR) — compromised SolarWinds' build pipeline and inserted backdoor code into an update for Orion, their widely-used IT monitoring platform. The malicious update was digitally signed by SolarWinds and distributed to approximately 18,000 customers, including U.S. government agencies, defense contractors, and Fortune 500 companies.

The attack went undetected for 14 months. During that time, attackers had persistent access to the networks of the U.S. Treasury, State Department, Homeland Security, and numerous other high-value targets. The total cost — direct remediation, indirect damages, and regulatory response — has been estimated in the billions of dollars.

Log4Shell — CVE-2021-44228 (December 2021)

Log4Shell was not a supply chain attack in the traditional sense — no one maliciously introduced the vulnerability. But it demonstrated the supply chain risk inherent in universal dependency on a single open source component.

Apache Log4j, a Java logging library downloaded over 400 million times, contained a critical remote code execution vulnerability (CVSS 10.0). It was present in products from Apple, Amazon, Microsoft, Cisco, and virtually every major software vendor — often buried four or five levels deep in transitive dependencies.

The key lesson was stark: organizations without SBOMs spent days or weeks just discovering where Log4j lived in their stack while attackers were actively exploiting it. Organizations with comprehensive component inventories could answer that question in minutes.

XZ-utils Backdoor (March 2024)

The XZ-utils backdoor was a sophisticated, multi-year supply chain attack that shook the open source security community. A malicious actor using the pseudonym "Jia Tan" spent nearly two years building trust as a contributor to the XZ-utils project — a compression library present in most Linux distributions — before inserting a backdoor designed to compromise SSH authentication on vulnerable systems.

The attack was discovered almost by accident by a Microsoft engineer investigating unexpected CPU usage. Had it gone undetected for even a few more months, the backdoor would have shipped in stable releases of Debian, Ubuntu, Fedora, and other major Linux distributions — giving the attacker persistent access to millions of servers.

This attack demonstrated something beyond the Log4Shell lesson: the threat is not only in known vulnerabilities — it is in the integrity of the supply chain itself. Contributors, maintainers, and the review processes of open source projects are themselves attack surfaces.

Why Traditional Security Approaches Fall Short

Supply chain attacks expose the blind spots in perimeter-focused security:

• Firewalls and network security do not help when the attack is delivered via a legitimate, signed software update
• Endpoint detection often cannot distinguish malicious behavior introduced in a trusted component from normal application behavior
• Penetration testing tests the perimeter, not the integrity of every dependency in your application stack
• Code review cannot scale to reviewing every commit in every open source library your application depends on
• Vendor security assessments assume vendors are not themselves compromised — an assumption SolarWinds disproved

How SBOMs Change the Response Equation

SBOMs do not prevent supply chain attacks. No technology does that comprehensively. What SBOMs do is transform the response — from a multi-week discovery-and-triage process to a minutes-long query.

Speed of Impact Assessment

When a new supply chain threat is disclosed, the first question is always: "Are we affected?" Without an SBOM, answering that question requires:

1. Manually scanning every repository for references to the affected component
2. Checking build artifacts and container images
3. Querying dependency lock files across multiple codebases and ecosystems
4. Accounting for transitive dependencies that may not be visible in top-level manifests

For a large organization with hundreds of services across multiple ecosystems, this can take days or weeks. During Log4Shell, many organizations were still discovering affected services three weeks after disclosure.

With a continuously-maintained SBOM for every deployed service, the question "are we affected by this Log4j vulnerability?" becomes a database query that returns in seconds. Impact assessment collapses from weeks to minutes.

Accelerated Remediation Prioritization

Knowing you are affected is only the first step. With an SBOM, you can also immediately quantify the exposure: how many services are affected? What is the severity? Which services are customer-facing versus internal? Which teams own the affected services?

This prioritization capability is the difference between an organized, risk-based remediation and a chaotic all-hands-on-deck response where high-risk systems are treated the same as low-risk ones.

Continuous Monitoring vs. Point-in-Time Scans

The XZ-utils attack highlighted that new vulnerabilities can be introduced into previously-safe components through malicious commits, not just new dependency additions. A point-in-time SBOM scan at deployment time is insufficient — the threat can materialize later, through a downstream dependency update.

Continuous SBOM monitoring — where your deployed component inventory is continuously cross-referenced against updated vulnerability intelligence — is the only way to catch these post-deployment threats before they are exploited.

The SCA + SBOM Defense Architecture

A mature supply chain security program combines several layers:

• SBOM generation at every build — creates the component inventory that all other capabilities depend on
• Vulnerability scanning against the SBOM — identifies known-vulnerable components before deployment
• License compliance — catches supply chain risk from license contamination
• Continuous monitoring — alerts when newly disclosed CVEs affect deployed components
• Integrity verification — tools like SLSA (Supply-chain Levels for Software Artifacts) and Sigstore provide cryptographic verification that build artifacts have not been tampered with
• VEX statements — allow vendors to communicate whether a CVE is actually exploitable in their specific product configuration, reducing noise for consumers

Key Takeaways

• Software supply chain attacks doubled in 2024 and have grown more than 700% since 2020
• SolarWinds, Log4Shell, and XZ-utils represent three distinct attack vectors — compromised build pipelines, vulnerable components, and malicious maintainers — all of which require different but complementary defenses
• SBOMs are the foundation of supply chain defense — they provide the component visibility that makes rapid impact assessment possible
• Continuous SBOM monitoring is essential — point-in-time scans only catch what was known at deployment time
• The attack surface is expanding to include AI models, training data, and ML pipelines — AI Bills of Materials (AIBOMs) are an emerging extension of SBOM practices to address these new vectors