Big Moments in Software Supply Chain Security

Introduction

Just over a year ago, I moved from Health Tech to a role at an Application Security (AppSec) company. My technical skills translated, but there was plenty of industry knowledge for me to catch up on.

In this post I'll take you through a timeline of the big moments in Software Supply Chain Security that everyone who works in AppSec assumes you know. For each one I've tried to distill the key facts and link out to the best resources I've found to learn more.

The Big Moments - A Timeline

April 2014 - Heartbleed

A buffer over-read vulnerability in OpenSSL (CVE-2014-0160) could allow malicious actors to read up to 64KB of server memory per request. When abused, this gave attackers the opportunity to read private keys, session tokens, user credentials, or other sensitive information on the server. The damage was compounded by OpenSSL's custom memory allocator, which recycled freed buffers internally without zeroing them-- keeping stale secrets readily accessible in a pool that specifically held cryptographic material, and defeating OS-level protections that might otherwise have caught the over-read.

OpenSSL is ubiquitous: an estimated 17% of TLS-enabled web servers were vulnerable at the time of disclosure. Yet the project had one full-time developer and received only ~$2,000 in yearly donations. The incident prompted the Linux Foundation to launch the Core Infrastructure Initiative to fund critical open source projects.

Failure mode: Vulnerable dependency in critical infrastructure.

March 2016 - left-pad

A trademark dispute between Kik Interactive and the author of several hundred npm packages led to npm siding with the company. The author responded by unpublishing all of his packages from the registry. One of them was left-pad, an 11-line function that pads strings with spaces or zeros.

Thousands of builds broke instantly. left-pad was a dependency of Babel, which was a dependency of practically everything in the JavaScript ecosystem. The incident revealed how deeply the npm ecosystem depended on trivial packages maintained by single individuals, and that removing a package from npm could break the internet in minutes.

npm responded by changing its unpublish policy to prevent removal of packages that other packages depend on.

Failure mode: Single point of failure in package registry.

September 2017 - Equifax Breach

On March 7, 2017 Apache disclosed a remote code execution vulnerability, CVE-2017-5638, in Apache Struts, a popular framework for building web applications with Java. Attackers first exploited the vulnerability against the credit reporting agency Equifax as early as March 10th. Starting May 13th, they began exfiltrating data, continuing undetected for 76 days. Approximately 148 million Americans had their personal data exposed, including Social Security numbers.

What many people don't realize is that Equifax had patched most systems in the first days after the vulnerability was disclosed, but they missed patching one particular system. The House Oversight Committee investigation found that they failed to patch it in part because they "lacked adequate asset management procedures" to identify affected systems.

Failure mode: Failure to patch known vulnerability.

November 2018 - event-stream

The maintainer of event-stream, a popular npm package with over 1.5 million weekly downloads, handed off maintenance to a relatively new contributor. The new maintainer added flatmap-stream as a dependency, a malicious package which contained obfuscated code targeting a specific Bitcoin wallet application (Copay). The malicious code was present for two months before discovery.

In a statement after the incident, the original maintainer had this to say about the dynamics of open source software maintenance:

I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. ...

If it's not fun anymore, you get literally nothing from maintaining a popular package.

Failure mode: Maintainer handoff exploited by malicious actor.

December 2020 - SUNBURST

Nation-state attackers compromised the build system for SolarWinds Orion, a network monitoring product used by thousands of organizations including US government agencies. The operational sophistication set the attack apart. The attackers inserted a backdoor (SUNBURST) into signed software updates, which customers then installed through normal update channels. The injected code matched SolarWinds' own coding style and naming conventions.

Because the backdoor arrived via signed, legitimate updates, it was indistinguishable from normal software maintenance. The attack went undetected for months. Around 18,000 organizations installed the compromised update, but the attackers selectively escalated on roughly 100 targets, including US Treasury, Commerce, and DHS.

Failure mode: Build system compromise.

December 2021 - Log4Shell

Log4Shell, CVE-2021-44228, was a remote code execution vulnerability in the Java library Log4j. The vulnerability allowed attackers to execute arbitrary code by causing the application to log a specially crafted string containing a JNDI lookup. Any input that eventually got logged could be used to trigger it, so exploitation was trivial to attempt at scale. The core architectural surprise was that Log4j, a logging library, could be induced to make outbound network requests and load arbitrary remote classes.

Log4j was and is used in countless applications. Often its inclusion is as a transitive dependency-- meaning not a direct dependency that you declare, but rather a dependency of your dependencies. Scanning tools could fail to detect it when Log4j had been repackaged inside other libraries under a different name. Many organizations didn't know if they were using it, or where.

Failure mode: Vulnerable dependency with ubiquitous adoption.

March 2024 - XZ Utils Backdoor

An attacker operating under the name "Jia Tan" spent approximately three years building trust in the xz compression library project through legitimate contributions. After becoming a co-maintainer, they inserted a backdoor targeting SSH authentication on Linux systems.

The backdoor was discovered by Andres Freund, an engineer working at Microsoft who noticed that SSH logins were taking ~400ms longer (500ms instead of 100ms) while performing benchmarking for PostgreSQL and investigated. The malicious code was weeks away from inclusion in major stable Linux distributions.

Failure mode: Multi-year social engineering to gain maintainer access.

December 2025 - React2Shell

The vulnerability known popularly as "React2Shell" (a name deliberately echoing Log4Shell), CVE-2025-55182, is an unsafe deserialization vulnerability in React Server Components that allows for remote code execution. The flaw exists in React's Flight protocol, which serializes component trees between client and server. Default configurations of popular frameworks like Next.js were affected, and exploitation requires a single crafted HTTP request and has near-100% reliability.

The vulnerability was discovered by Lachlan Davidson on November 29th, 2025. Vercel coordinated responsible disclosure to major cloud providers before public disclosure on December 3rd, which allowed them to deploy some protections before attackers had access to public exploits. Attempts to exploit the vulnerability by nation-state actors began within hours of disclosure.

Failure mode: Vulnerability in framework-level serialization boundary.

Wrap up

Look at what connects these incidents and you'll find the same structural problem almost every time: software that the world treated as infrastructure, maintained by people the world treated as volunteers. Every few years the consequences surface, we pay attention briefly, and then we go back to taking it for granted.

I watched most of these events from the sidelines-- reading Hacker News comments or watching YouTube breakdowns after the fact. React2Shell was different. Responding to it was my job. I was reading the React team's announcement within minutes of publish, trying to figure out what we knew, what we didn't, and how to advise customers while operating in that uncertainty.

I co-authored an article at Endor Labs in the early hours of response to React2Shell. You can read that here:

→ Critical Remote Code Execution (RCE) Vulnerabilities in React and Next.js

Bonus Reads

Some foundational reads that commonly come up in conversations about Software Supply Chain Security.