When the concept of software supply chain security first became a focal point of discussion in 2020, I found myself deeply immersed in trying to define it within a specific context. At the time, I was working at In-Q-Tel, a strategic investor for the U.S. intelligence community, and co-authoring a research paper aimed at measuring the frequency of software supply chain attacks. For our purposes, we decided on a definition that focused on instances of malicious software being introduced into existing distribution channels. This approach seemed logical at the time—attacks typically exploit existing systems and mechanisms for software delivery. However, as soon as our paper was published, this definition was challenged repeatedly by real-world events that demonstrated the limitations of such a narrow scope.
Fast forward to the summer of 2024, and the landscape of software supply chain security has shifted dramatically. The security incidents we’ve seen in the past few years have made it evident that a more expansive definition is required. After grappling with the complexities and seeing the results of numerous attacks, it has become clear that software supply chain security cannot be understood through a simple lens—it must be viewed as part of the broader spectrum of software security itself. This evolution in thinking has led to a more inclusive definition, one that encompasses not just attacks on distribution systems but also the vulnerabilities introduced at every stage of the software development lifecycle.
Looking back, the original definition I worked with focused heavily on the propagation of malicious code through established distribution channels, such as compromised software registries or backdoored compilers. It was a straightforward way to categorize the issue, focusing on where the malicious functionality entered the system and how it spread. For instance, the paper broke down attacks into two major categories: those targeting build, source, and publishing infrastructure, and those attacking software registries. The first category included threats like back-doored compilers, which had been famously discussed in Ken Thompson’s seminal article on software security. The second category, more prevalent in recent years, was the discovery of malicious open source packages in popular software registries.
However, as attacks grew in scope and sophistication, it became clear that this approach didn’t fully capture the complexity of the problem. The traditional definition didn’t account for the multitude of risks posed by interconnected systems, vulnerable dependencies, and the ever-growing complexity of modern software development practices. To address this, I had to come to terms with a more fluid and expansive view of software supply chain security—one that sees security as a continuous thread running through every facet of software creation, distribution, and maintenance. In this broader context, securing the software supply chain is no longer about preventing a few well-placed attacks but about mitigating a range of vulnerabilities that can emerge at any point in the development pipeline.