Understanding the relationship between FOSS and the “software supply chain”

Security concerns regarding the consumption and distribution of software have been a hotly debated topic in the past few years since the SolarWinds and Log4Shell incidents. In the software industry, these discussions have largely culminated into the topic of “software supply chain security” and how the “software supply chain” can be improved.

‍

Many of the proposed initiatives – such as SPDX and SBOMs – predate the software supply chain discussion and were originally largely centered around legal compliance. At the same time, there has been some resistance from developers who believe, based on recent discussions, that they will be hit with new burdens simply because they are releasing free and open source (FOSS) software to the general public.

‍

First, FOSS maintainers are not and should not be considered software suppliers. When maintainers write, “I am not a supplier,” others, in my opinion, should nod and agree. This is a simple matter of FOSS licenses, which provide software “as is”and with no warranty. But to agree that FOSS maintainers are not suppliers does mean that consumers are wrong to ask for FOSS that can be trusted. It’s just that software distributions, not maintainers themselves, ought to be the “supplier,” the party that’s held responsible.

‍

What is the “software supply chain” really?

Let's begin with the hot button topic at hand. There’s now a “software supply chain” and everyone is talking about it. But is it really new? The answer is actually no: what we are now calling the “software supply chain” is simply the topic of software distribution at large. End users consume software from distributors, and distributors source software from suppliers. Thinking about software distribution in these terms makes a lot of sense, but can seem scary. As in actual supply chains, there can be legal liabilities for distributors and suppliers if they make mistakes. However, for software distribution, almost all FOSS licenses provide a waiver of liability for the original author of the software. As an example, we can look toward the GNU GPLv3 for an idea of what these waivers look like:

‍

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

‍

16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

‍

17. Interpretation of Sections 15 and 16.

If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.

‍

When users download and install a GNU/Linux or another FOSS operating system, they are participating in a software supply chain as a consumer: the project producing the FOSS operating system acts as a distributor. This is why Linux distributions are named Linux distributions. Community-run distributions provide their users with their own waiver of liability, while commercial distributions such as Chainguard Images come with Service Level Agreements and other guarantees as a value add. In other words, users who subscribe to Chainguard Images are paying for Chainguard to mitigate the risk of consuming third-party software.

‍

Any relationship where there is a party acting as a middleman between the author of a software package and the user of a software package can be described in the same way as a “software supply chain”, but historically would have been described as a “software distribution”.

‍

Software distributions rightly set their own rules for what they will distribute

Outside of the system-level software distributions, many language ecosystems have launched their own package registries. These act as software distributions for specific programming language ecosystems and have historically been more lax on what they will accept into their distributions. Bad actors looking to compromise end users who consume software from these distributions have engaged in a number of different attack methods. Some examples include attacking end users through typosquatting or compromising developer credentials.

‍

Concerns about bad actors have resulted in package registries introducing policies that restrict who can publish packages and how they are published. Some in this debate have viewed this as an overstep, arguing that these distributors have no legal liability for the software they are distributing. However, I believe that this position over-indexes on legal liability while failing to consider the reputational damage caused to package registries when security incidents happen. It is right for a distributor to impose controls in order to ensure the registry can remain generally trustworthy.

‍

Some developers argue that these proposed new controls, such as having CI/CD systems create and sign releases from git tags, are inconvenient. This can be true, depending on the developer’s workflow for software releases. However, these controls also help to enforce the boundaries that developers set when they release software, such as legal indemnification. For example, if a developer’s project is attacked by a threat actor and a compromised package is released, if that developer chose to use Sigstore, in most cases, it would be possible to determine that the compromised release was not signed by a key related to the developer’s OpenID Connect identity. This is important because if your project is widely used and considered key infrastructure in modern society, no amount of legal indemnification statements in your software license will prevent a congressional subpoena. In the end, these controls exist to protect both the reputation of the developer and the distributor in the event of a security incident.

‍

This isn’t really about corporations…

A number of people in the FOSS community talk about how the “software supply chain” push is really about making it easier for corporations to abuse the commons. This couldn’t be further from the truth. For example, SPDX was originally created for the purpose of making GPL and other FOSS license compliance easier. However, putting the history of SPDX aside, it is standard practice for corporations to have internal controls which require every software component they consume to have an internal maintainer if they are not consuming it from a supplier. This internal maintainer takes the responsibility of ensuring that the software is working properly for the organization, and may occasionally report bugs or send fixes to the upstream project, but generally is intended to not be an annoyance to the upstream maintainer.

‍

At the same time, it is also true that some software engineers at some companies have taken it upon themselves to engage with FOSS projects which they want to use as a dependency as if they were legally in a supplier role. I personally receive several inquiries of this nature a year, usually asking me to fill out the Consensus Assessment Initiative Questionnaire, a 200 question security posture assessment for a software component for one of the libraries I maintain in my personal capacity, such as libucontext or pkgconf. Engineers should never engage with maintainers in this way, as it can be annoying, but it is not a burden. In these cases, I usually just ignore the request, as they should be engaging with a commercial FOSS distributor (such as Chainguard – we are happy to help!) if they require these services.

‍

So what is the software supply chain really about? It’s about the relationship between software distributors, like Chainguard, and software consumers. It’s not particularly about FOSS projects themselves, although if maintainers want to, they can take steps to help protect the larger FOSS ecosystem from bad actors. This provides tangible benefits to all participants in the FOSS ecosystem, from maintainers, to direct consumers, to software distributors which have to vet packages. Software distributors have already been vetting packages since the beginning of software distributions and, ultimately, whether upstream projects sign their releases or not changes very little with the vetting process from that perspective.

‍

There are three key takeaways on software distribution I want to leave you with today:

‍

• Nobody can prevent you from writing your own software!

• Consumers can ask you for things, but they can't require them

• If you want to distribute your software via a particular channel, you need to follow that channel's rules

‍

If you have thoughts or additional insights about the topics I covered in today’s post, please reach out to me on Mastodon.