When software isn’t a “supply”

Editor’s note: The following think piece, written by Snyk’s Open Source and Open Standards Strategy Director, Daniel Appelquist, examines the origin of the term “supply chain security” and whether it’s a good fit for today’s open source software development process.

I was inspired to write this after reading a post from Thomas Depierre on Mastodon:

The post touched on something that’s been troubling me recently. When it comes to software security, we spend a lot of time talking about the software supply chain and related concepts, such as the software bill of materials (SBOM). This metaphor comes from an industrial lexicon. People who are used to talking about economies and how manufacturing works are familiar with the idea of supply chain. So when we’re talking about software — especially open source software, with its set of nested dependencies — it’s understandable why many in the industry have grasped onto this metaphor. It’s a shorthand way to explain modern software development to people who may not understand concepts like dependencies. 

However, like many useful metaphors, it’s inexact and can only be stretched so far. The supply chain metaphor is intended to refer not only to the maintainer, but to the entire ecosystem and everything in between to get a library to an open source project. For example, the npm registry is one "supply" source, while the GitHub Actions marketplace is another.

Some people like to treat the open source world as one contiguous community. The reality is that open source is highly factionalized. There is a more corporate side to open source, sometimes called the “open source / industrial complex” — for which the terminology around supply chain would be completely appropriate. On the other side of the spectrum is the free software movement, which would likely find the concept of “software supply chain” anathema to their way of thinking. And there is a huge spectrum in between.

In his post, Thomas quite rightly points out that there is no actual supplier agreement inherent in open source software dependencies. In that sense, a developer of OSS is not a supplier to upstream projects. The use of the “supply chain” metaphor can cause misunderstandings — as when open source software project maintainers receive legal notices or letters from companies. Indeed, this very thing happened during Log4j. Open source developer Daniel Stenberg (famous for his foundational work on the Curl project) received letters from a (well meaning) corporate procurement team regarding the Curl project, which treated Daniel as a supplier, compelling him to provide data about use of Log4j in Curl within a strict timeline. While this kind of communication might be appropriate in a strict supplier relationship, which is codified in a contract with a service level agreement. It’s not appropriate  — at all — in an open source context.

I think the nomenclature and mental model around software supply chain is still a very useful construct, especially when communicating with policy makers or other decision makers who are unfamiliar with software dependencies or how open source works. However, this metaphor only goes so far. When we use it, we should also be cognizant of the fact that open source dependencies are not a supplier agreement, and more importantly, there is an entire community of open source software developers out there who do not view themselves in this way. The software security complex needs to be a big tent — inclusive of those people and communities who may not be as comfortable with the “supply chain” way of thinking  — if we want to achieve the goal of leveling up software security across the industry.

So how could we address this problem? I think we should consider adopting a slightly different nomenclature in some contexts. The term software dependency chain might be more appropriately used when the context is the general open source developer community. Or we, as an industry, need to explain very clearly to open source developers what we mean, and don’t mean, by software supply chain.