Clear and Present Danger to the Software Supply Chain
In general, any manipulation of any element of the software supply chain puts the whole software ecosystem in danger and can cause severe damage. This is not limited to other software projects but also affects the real world as basically everything and everyone is dependent on software in our modern world. This can range from the inconvenience of being unable to pay with your phone to the catastrophic failure of essential infrastructure, causing countless deaths.
Besides you and me, big tech and governments worldwide also realized that software is essential and that the software supply chain is fragile. Thus, initiatives and programs like the CVE and the GitHub Advisory Database were introduced to coordinate and communicate security issues in libraries and applications. Furthermore, the US President also issued an executive order to improve cybersecurity to counter recent hacks and ransomware attacks. Combined with the trend towards DevSecOps, it shows the growing importance of this topic and the attention it is receiving.
Legacy Security
Regarding software repositories, SLSA is another initiative that focuses on tracking software artifacts along the software supply chain. Generally, it provides significant improvements to the various steps of the processes of creating, distributing, and obtaining artifacts that are used in software projects.
But like other security solutions1, it is built upon trust models that do not scale to the global level and our evolving world. SLSA Level 3 addresses source and build platforms and defines that they must meet specific standards, guaranteeing the integrity of provenance and other artifacts. This is basically a great idea. However, the question is how compliance with these standards is achieved.
This is where the authors of SLSA point to the usual Compliance Buzzwords, auditing, certifications, and ISO-Something, to verify that repositories and other infrastructure are safe to use. Again, in a perfect world, this would work fine. But does a centralized trust model suffice?
Does an audit of a public software repository like the NPM Registry, a system operated by a privately held company, guarantee that neither the repository nor the people involved act maliciously? What does such an audit signify, as it is just a snapshot in time? Who is this auditor, and why should we trust them? Why should you believe the word of whoever on something happening behind closed doors?
These are just some of the questions you should ask when you read such a proposal.
No Trust is Better Trust
Trust in Few
The authors believe open-source software development and the software supply chain have reached global and vital significance. Hence, entrusting the management and ownership of essential elements to a few entities is inherently risky. Individuals, companies, and governments will eventually pursue their interests and take advantage of their positions, leaving the community with a broken or compromised system.
The proper, uninterrupted operation of all software supply chain elements supersedes all other interests2 and must be guaranteed under all circumstances.
Removing the component of trusting in people and institutions to prevent the misuse of power is imperative. It provides the bases of a system that cannot be compromised by some party to enforce their agenda on everyone.
Trust Reduction
Democratic systems try to remove the power from the hands of the few and give every participant a voice in the decision-making process. Real-world adaptations, however, still centralize power and are, as we all know, flawed. Moreover, corruption and manipulation in politics are not just the stuff that makes incredible books and movies but is very real and even partially legalized through, for example, lobbying.
The trust models we commonly use were created when there was no internet. However, instant global communication and modern cryptography allow the creation of new models suitable for the current state of the world.
We envision a trustless system built upon basic rules we all can agree on. It fulfills its functionality, nothing more and nothing less. By being axiomatic, simple, and versatile, it is a building block for larger systems.
A modern software repository must be just that, a software repository. It holds and serves software artifacts to anyone worldwide, with no exceptions. Likewise, anyone can add new software without the approval of an administrator. It is a system that is reliable in terms of its service. Individuals, companies, or governments cannot censor or modified it.
Decentralized systems can provide these properties. We propose a software repository built upon modern decentralized technologies and mindsets. It is driven and secured by its user community and cannot be compromised. Cryptographic truth and immutable code replace the need for trusted parties to uphold the systems’ rules. A decentralized repository (dRepo) provides security along the whole supply chain, from software development over software distribution to software execution.
-
For example, signing container images using Docker Content Trust and the certificate chains we use to secure the web are all good ideas that are fundamentally flawed. ↩︎
-
This does not necessarily include human rights violations or the direct endangerment of individuals. However, corporate greed, political suppression, limiting the freedom of speech, and the like cannot be allowed. ↩︎