The definition breaks down
A mere three months later, a new type of attack materialized that didn’t fit within the existing typology. A new attack type called “dependency confusion” was coined when security researcher Alex Birsan self-published a Medium article sub-titled “How I Hacked into Apple, Microsoft, and Dozens of Other Companies.” What was clever about this new attack type is how it took advantage of the non-intuitive behavior of package managers, allowing an attacker to trick developers into downloading malicious code from an external package registry rather than, as planned, an internal package registry. While similar to typosquatting, which was already a minor category in our typology, this attack didn’t actually involve a typo. Our original definition of software supply chain security had already been stretched. We added another minor category and moved on.
Then in December 2021, Log4shell happened and the “internet was on fire.” Now our typology suffered a mortal wound. The earlier typology focused exclusively on the insertion of malicious code, but the Log4shell vulnerability didn’t involve malicious code. Nevertheless, Log4shell clearly represented a widespread vulnerability in the software supply chain. It was an easily exploited and severe vulnerability, introduced by a flaw in a widely popular open source Java logging library. The episode revealed a crucial flaw in our existing definition of software supply chain security: unintentional security flaws in widely used open source software had no place. That original typology, for the purposes of my career, was dead only 18 months after invention.
Accepting a broader definition
Upon reflection, the “supply chain” aspect of software supply chain security suggests the crucial ingredient of an improved definition. Software producers, like manufacturers, have a supply chain. And software producers, like manufacturers, require inputs and then perform a manufacturing process to build a finished product. In other words, a software producer uses components, developed by third parties and themselves, and technologies to write, build, and distribute software. A vulnerability or compromise of this chain, whether done via malicious code or via the exploitation of an unintentional vulnerability, is what defines software supply chain security. I should mention that a similar, rival data set maintained by the Atlantic Council uses this broader definition. (Full disclosure: I’m now a non-resident fellow at the Atlantic Council. If you can’t beat ‘em, join ‘em.)
