Software Supply Chain: The Attack Vector That Grew 742% in Three Years

Log4Shell, discovered in December 2021, affected an estimated 3 billion devices worldwide. The vulnerability was in an open source library used in tens of thousands of applications — many of them in organizations that had never heard of Log4j before the crisis. It didn't matter how sophisticated the security team was: if the software you bought, contracted, or downloaded used the library, you were exposed.

This is software supply chain risk in its purest form: the vulnerability is not in your organization, not in the direct vendor, but in a component that the vendor's vendor uses. And you only find out when it is already too late.

Why supply chain attacks grow faster than direct attacks

The logic is economic. A large company with a mature security team can have robust defenses: advanced EDR, 24x7 SOC, network segmentation, universal multi-factor authentication. Attacking it directly is expensive and uncertain.

But that same company uses 50, 100, 200 software vendors. Each one is a potential attack surface — and many have privileged access to the company's systems: monitoring agents with root access, CI/CD pipelines with deploy credentials, API integrations with access to customer data. Compromising one of these vendors means compromising all of its clients simultaneously.

The Sonatype 2023 report documented 245,032 malicious attacks on open source software repositories — a growth of 742% compared to 2020. This is not a trend. It is a structural change in the threat landscape.

What makes software supply chain different from traditional TPRM

Traditional TPRM assesses the vendor as an organization: its processes, policies, general security posture. Software supply chain requires an additional level: assessing what the vendor delivers — the code, dependencies, components — not just how it operates.

A vendor can have ISO 27001, documented secure development processes (SSDLC), and a competent security team — and still deliver software with a vulnerable dependency at the third level of the dependency tree, because nobody mapped that far.

SBOM: visibility as the first control

Software Bill of Materials (SBOM) is the inventory of all components in a software — libraries, direct and transitive dependencies, their versions and licenses. It is the equivalent of an ingredient label for software. President Biden signed an executive order in 2021 making SBOM mandatory for software acquired by the US federal government. The regulatory trend is global.

For risk managers, the practical question is: can your critical software vendors provide an SBOM? And do you have a process to cross-reference that SBOM with vulnerability databases (NVD, OSV, CISA KEV) on a continuous basis — not just at contracting?

Priority controls for risk managers

Beyond SBOM, the controls with the highest return for mitigating software supply chain risk include: (1) Vendor access segregation — no third-party agent should have broader access than strictly necessary for its function. (2) Update integrity monitoring — verifying digital signatures of packages and updates before applying to production. (3) Anomaly detection in pipelines — identifying atypical behavior in CI/CD processes that may indicate compromise. (4) A specific incident response plan for supply chain incidents — which differs from a conventional incident, because the initial vector is outside your control perimeter.