In the spring of 2020, the question of what exactly “software supply chain security” meant was something that weighed heavily on me. At the time, I was working at In-Q-Tel, a strategic investor for the US intelligence community, and was co-authoring a research paper aimed at measuring the frequency of software supply chain attacks. For our paper, we decided on a definition that focused on the distribution of malicious software through existing channels. This seemed like a clear and logical approach, given the nature of attacks we were investigating. However, almost immediately after the paper was published, we found that this definition began to break down in various ways.
Fast forward to the summer of 2024, and after several major software supply chain incidents, I’ve come to realize that defining software supply chain security requires a far broader perspective than we initially imagined. The definition that once seemed so straightforward now feels inadequate in capturing the full scope of what constitutes a software supply chain attack. In fact, after witnessing how frequently and varied these attacks can be, I’ve accepted that the only workable definition is so expansive that it could even be seen as encompassing all of software security itself. This shift in perspective has been the result of both mounting incidents and an ongoing process of reflection on how we define the problem.
Looking back, this piece serves as a reflection on my evolving understanding of software supply chain security—how I grappled with pinning down an initial definition, how I confronted the growing evidence that the definition needed to be reconsidered, and how I eventually accepted the need for a much broader understanding of the issue. What once seemed like a niche problem tied to the distribution of malicious code through specific channels has become a much larger conversation that touches nearly every aspect of software development and maintenance. The realization that software supply chain security is intertwined with the overall security of the software ecosystem itself is a fundamental shift in how we should approach these threats.
The original definition that we settled on for our research paper seemed reasonable at the time. It focused on instances where malicious functionality was intentionally inserted into the build, source, or publishing infrastructure of software, or into the components themselves, with the goal of propagating through established distribution channels. This definition was built around the idea of malicious code being distributed through existing mechanisms—whether it was a compromised build tool or a malicious package in a popular software registry. However, as we analyzed the landscape of software supply chain attacks and reviewed the data, it became clear that our definition was too narrow to account for the broader, more complex landscape of modern attacks. Our understanding of what constitutes a “software supply chain attack” was simply not keeping pace with the sophistication and frequency of the incidents we were witnessing.