Securing The Supply Chain

Clear and Present Danger to the Software Supply Chain

In general, any manipulation to any element of the software supply chain puts the whole software ecosystem in danger and can cause serious damage. This is not just limited to other software projects but also affects the real world as basically everything and everyone is somewhat dependent of software in our modern world. This can range from the inconvenience of not being able to pay with your phone to the catastrophic failure of essential infrastructure causing countless deaths.

Besides you and me, big tech and governments around the world also realized that software is important and that the software supply chain is fragile. Thus, initiatives and programs, such as the CVE and the GitHub Advisory Database, were introduced to coordinate and communicate security issues in libraries and applications. To counter recent hacks and ransomware attacks the U.S. President also issued an executive order to improve cybersecurity. In combination with the trend to DevSecOps this shows the growing importance of this topic as well as the attention it is receiving.

Legacy Security

Coming back to the topic of 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 in the processes of creating, distributing and receiving artifacts that are used in software projects.

But like other security solutions¹ it is built upon trust models that do not scale to the global level and the evolving world we live in. SLSA Level 3 addresses source and build platforms and defines that they have to meet specific standards so the integrity of provenance and other artifacts is guaranteed. 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 ususal 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 which is operated by a privately held company guarantee that neither the repository nor the people involved act maliciously? What does such an audit actually mean 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 that is 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

It is the authors’ opinion that open source software development and the software supply chain have reached a level of global, vital significance. Hence, entrusting the management and ownership of essential elements to few entities is inherently risky. Individuals, companies, and governments will eventually pursue their own 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 interests² and must be guaranteed under all circumstances.

Removing the component of trusting in people and institutions to prevent the misuse of power is a necessary action. It provides the bases of a system that cannot be compromised by some party to enforce an 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, not flawless. Corruption and manipulation of politics are not just the stuff that makes great books and movies but are very real and even partially legalized through for example lobbying.

The trust models we commonly use were created when there was no internet. Instant global communication and modern cryptography allow the creation of new models that are 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 in the world, no exceptions. Likewise, anyone can add new software without approval of an administrator. It is a system that is reliable in terms of the service it provides. It cannot be censored or modified by individuals, companies, or governments.

Decentralized systems can provides these properties. We propose a software repository that is 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 who have to uphold the rules of the system. A dezentralized repository (dRepo) provides security along the whole supply chain, from software development over software distribution to software execution.