Is There a Better Way?
By Luca and Mitja Goroshevsky
Putting aside our biases, we aim to answer, briefly and as objectively as possible, how other solutions available on the market right now are answering the requirements of Software Supply Chain security.
The release of GOSH coincided with a rising interest in decentralized open source development tools. Web3 projects will naturally look not only to deploying, but also to storing, developing, and managing code in a decentralized environment; and, of course, many projects that aren’t Web3 as well. While there are only a handful such tools currently on the market (and even that is a stretch), we welcome the few in use.
One of GOSH’s stated goals is securing the Software Supply Chain. In the following text we will be exploring the requirements to fixing this problem and reviewing how two of the other available solutions are answering them.
This is not an exhaustive study of all current projects. We are only including two which we feel are the most mature. If there are any other projects you know of, we would love to hear about them.
There is naturally a degree of fragmentation among various solutions to Supply Chain security. Some projects fix one hole, some fix another. If software development goes down this route, developers will have to simultaneously juggle many tools in their workflow, a lot of which have to be managed manually. GOSH, however, was built with the idea that security can be achieved with no workflow adjustment; offering developers the familiarity of git, only with a guarantee of fully securing their Supply Chain. We can achieve this because only the blockchain can secure all of the components of the Software Supply Chain in one combined solution.
The reason is simple. In order to achieve Software Supply Chain security, developers need immutable artifact storage and automation. That is to say: all Dev and CI/CD artifacts should be created by a Supply Chain trustless execution flow and be stored in an immutable way, in a particular order with a consensus timestamp attached to them. Let’s elaborate further.
The Source Code
The main Software Supply Chain artifact is, naturally, source code.
The low level attack vector is on the source code itself, via attacks on repositories. Attackers can gain control of a user machine, insert malicious code right into it, and recalculate all of a git hash tree. An attack on the git cloud is a little trickier because of a discrepancy that a local copy is on the developer machine. Yet it can also be done, through an otherwise legitimate commit to a repository, adding, for example, a new contributor with malicious intent. Another way to attack the repository, as we have recently witnessed and written about here is through social engineering, with a malicious commit into a legitimate repository or by convincing developers to use a forked ‘fake’ repository instead of a legitimate one.
Decentralized Management
To mitigate these attacks, the source code must be immutable. Changes to the source must be attributed and traceable. Manipulations of source should be automated only with verifiable scripts executed in a trustless environment. Access and ownership rights to a repository should ideally be managed in a decentralized way and be censorship resistant. Whenever possible, consensus should be built around code decisions which limits drastically most of the ways source code can be exploited.
Cryptographic Signatures
User side security is when the user controls its private key. With every artifact signed by a cryptographic signature, the chain of custody, tracing software back to the source, is established. This allows developers to know that whoever signed an artifact, holds the keys; to trace source to its authors and verify their identity as well as reputation. On the blockchain, smart contracts verify signatures and automatically create immutable artifacts used in software supply chain automation.
Data Availability
Developers should always know that artifacts and all their metadata, including logs, are always available. This is a harder problem than it appears. Blockchain provides guarantees of data availability that no cloud platform can. Writing just a hash of the original data isn’t enough, because the original data may not be available to verify the hash correctness or the hash may not be available to verify the source data. The artifacts created by the Supply Chain are part of that data as well as script execution results (a transaction) that are recorded. These records are not only immutable but also constantly available for verification.
Trustless Execution
There are critical parts of the Software Supply Chain which entirely depend on the execution of programs on remote servers. We are talking about CI/CD scripts which often include running tests, container builds, packages and so on. Script execution, if tempered with, can jeopardize more or less everything regarding your Software Supply Chain. One single malicious line executed within such a script can create catastrophic events in your organization or project, from stealing your security keys, to deploying back doors, trojan horses and other viruses on your customer computers. There is no end to the amount of damage that can be done.
Trustless execution ensures that a computation is verifiable. The result of the execution is recorded (state updated) the moment it occurs. Immutable logging with record time proofs is always available, and the artifacts are stored in an immutable log at the time of execution with a provable timestamp.
Now let’s briefly see how two projects aiming to facilitate decentralized software development and security may or may not meet these requirements.
Sigstore
Sigstore is not a blockchain project. Their solution uses Cosign to generate the key pairs needed to sign and verify artifacts. It also uses Rekor, an “immutable log and timestamping service.” Rekor is built on a Merkl tree without a consensus layer.
Now, consensus layers were invented for a reason. Without consensus you can only prove the record belongs to a tree, you can never prove when a record was created and if the record itself is correct. The immutability in Rekor just means that the hash, once inserted, can not be changed. It says nothing about the validity of the record itself. Data is only available as long as the service runs.
✅ Cryptographic signatures
❌ Decentralized management
❌ Data availability
❌ Trustless execution
❌ Immutable logging with record ordering and time proofs
Radical
Radical is also not a blockchain project. It is a p2p collaboration layer on top of Git. More like a Git federated cloud. It offers a user side PK cryptography layer but can not trace them either to reputation nor profiling. While this allows developers to prove some things by putting some hashes on the blockchain, the data is not available. There are no verifiable script execution capabilities, and though it may work for code development, it cannot work as a Software Supply Chain security solution.
✅ Cryptographic signatures
❌ Decentralized management
❌ Data availability
❌ Trustless execution
❌ Immutable logging with record ordering and time proofs
To Conclude
Both Sigstore and Radical are great solutions. We praise their incredible work in fixing crucial problems. However, we do not believe they are the best for Supply Chain security. While both Radical and Sigstore can patch their design to enable security features, that would inevitably lead them to a design quite similar to GOSH.
To stay updated on everything we’re up to here at GOSH, try subscribing.