Introducing AnyTree
The First Software Deployment System Secured By A Blockchain
Part I: Give It To Me Straight, Doc
One of GOSH’s much touted aims is to secure the software supply chain. This matter has become of late ephemeral, somewhat hush, even nebulous perhaps. We have spoken at length about open source management, decentralized science, and other such matters, but we know why you’re really here. Supply chain security is the matter on everyone’s mind, and now, at last, the solution GOSH has been developing since its inception has seen a major breakthrough:
GOSH is proud to introduce AnyTree — the first software deployment system secured by a blockchain
TL;DR
Software distributed through AnyTree is secured at the source, cryptographically signed, and based on Deep SBOM technology pioneered by GOSH, which describe not only what, but also how something was built
On AnyTree, whatever apps developers distribute or use, are delivered exactly as they are supposed to be — only code developers write is included
AnyTree secures the delivery of any package you use today. AnyTree works with almost any package manager, (including NPM, MAVEN,... ) user or server applications — the way you deliver packages today, you deliver them with AnyTree
AnyTree Packages can be downloaded from Docker Hub, GOSH Docker Desktop Extension and AnyTree native applications (coming soon)
If an app is distributed by AnyTree it is guaranteed to be secured by GOSH with all its dependencies, build and compiler environments, built in isolation and cryptographically signed and timestamped
GOSH has collaborated with Ambassador Labs to assure the integrity of Docker Containers. The GOSH AnyTree Firewall for Telepresence adds an extra layer of security for Telepresence users by verifying the integrity of Docker containers as well as any changes made to them and builds Docker containers only from approved sources
AnyTree utilises standard Docker Containers secured by GOSH Builder and is currently available as Beta on Linux and is coming soon to Mac and Windows
Part II: The Meat
“It’s not that you wrote a bug in your code — it is that other people wrote bugs in their code and you’re using what they built.”
This is a quote from a recent MIT lecture on software supply chain security by Jon Gjengset. In order to best explain GOSH’s latest advancement to securing the software supply chain — AnyTree, for those of you who don’t like TL;DR passages and like to jump right into the meat (we salute you) — we will address key points Mr. Gjengset makes in his lecture step by step.
“Supply Chain security is basically these three questions:
What Are You Deploying Where?”
The conclusion the speaker arrives at when outlining the steps businesses and developers can take to know what code they are deploying where is quite simple: every deployment should be logged.
The seemingly natural solution, chosen by some supply chain security providers, should be transparent logs. In one of our very first articles we outlined why we chose to avoid transparent logs as our central solution:
“Logs stored on servers are centralised by nature. This means that, by inherent design, all their critical operational infrastructure relies on many potential points of failure”
“The transparency log cannot be altered unless the root is altered. But there is no trustless infrastructure to independently verify this. As a user, you need to trust the certificate”
“Only on the blockchain is it possible to prove ‘order of time’”
Indeed the keyword is ‘blockchain.’ Though much maligned, blockchain is primarily a distributed ledger, and so being in agreement with the speaker’s claim as to the importance of logging we naturally set out from an assumption that blockchain technology is an ideal solution to the problem of how to survey what you’re deploying. The only catch, the one thing needed to make this solution feasible is: in order for this to work everything must be deployed on the blockchain.
If you don't have a relationship between your logs and the blockchain, you shouldn’t trust them at all.
With AnyTree, any mutations of your code, down to every dependency, are logged on the blockchain; AnyTree operations, including builds and every artefact (and Deep SBOM itself!) are all, you guessed it, logged on the blockchain.
We achieve this through a unique blockchain architecture in which every single object on GOSH is wrapped in a smart contract that is executed instantly upon a user’s command — this is what allows us to build AnyTree, an unparalleled tool to allow developers to log, and clearly tell what they are deploying where.
“2. Do You Know Where It Came From?”
“How do you know?” Asks Mr. Gjengset on the 14th minute, “Even if somebody puts on their website ‘we checked everything, trust us,’ they have a stamp on there and they signed their name, it doesn’t really matter if you don’t have a way to verify that they actually went through the steps.”
In tackling the origins problem in software, we again invoke our use of the blockchain. Signatures and any commits made on GOSH are immutably produced on-chain. This, in effect, means that any apps developers distribute or use on AnyTree are delivered exactly as they are supposed to be — only code developers write is included — and can be traced back to the source and verified that they were really built on GOSH.
While blockchain technology has most notoriously been used in the development of cryptocurrencies, we feel the potential of a decentralised ledger is somewhat limited in just that one use case. The fact that GOSH AnyTree is a blockchain product means that when, as we mentioned before, something is traced, verified, and produced on-chain, it does not require you to trust any additional party or take on any new dependency, to trace its origin. GOSH AnyTree provides concrete cryptographic guarantees when storing git objects, and tracing software, that allows you to know whether or not it came from GOSH. And if it didn’t, you know there’s a problem.
Let us give an example: A major potential attack vector in the software supply chain is the suspect security of package delivery. With the aforementioned emphasis placed on cryptographic guarantees, AnyTree allows you to secure the delivery of any package you use today, without changing the way you deliver packages.
AnyTree works with almost any package manager, (including NPM, MAVEN, Python, etc.) user or server applications. If you use AnyTree to build your NPM, Maven, or Python package, you have full visibility of what goes into it, and where it came from. Something you just don't have while building with a current package manager.
Because it is based on cryptography to verify the origins of your software, AnyTree allows you to see the source code used to build this package, and mitigates against a multitude of attack vectors by ensuring that nothing else, no malicious scripts, makes it in. Now, of course, if you are a malicious developer and you maliciously put only malicious code into the package, we cannot secure against that. Mr. Gjengset’s rule applies:
“Ultimately you’re at the mercy of authors. What this means is, when you’re taking dependencies, you want to think really critically about who you are taking dependencies from.”
But most workflows do not come down to a simple “pure vs. purely malicious” dilemma. Most packages, even tainted ones, have a clean source, otherwise no software would ever work. And any package you deliver with AnyTree is secure and stays secure — offering both developers and end users transparency of the code and the tools with which it was built.
“3. What’s In It?”
Perhaps the major challenge to software supply chain security is observability, and the "What's In It?" aspect of observability is arguably its most important part. Once you have a solution, you can have an observability tool that is connected to your monitoring or other frameworks, and that constantly monitors your infrastructure. This can be done proactively, or to observe, say, a Kubernetes cluster and report on what is currently on it. You can then build everything else on top of this, such as check actions and triggers for security vulnerabilities.
To effectively monitor something, one must have a deep understanding of the object being monitored. This is a challenging task, as it requires a thorough knowledge of the object's inner workings. The only way to do this is if you have a very detailed and up-to-date software bill of materials (SBOM). Currently, however, these are always written post-factum. This is insufficient, as it does not provide real-time information about the object's contents. Deep SBOM was created to address this need, providing a comprehensive view of the contents of your supply chain in real time. Here’s how it works:
All repositories on GOSH are bound by the same immutable timestamped history
While Git users with Repository Owner Keys can insert malicious code recalculating the repository history, it is practically impossible to inject malicious commits backwards on GOSH
AnyTree adds to this security by making it very hard to miss dependency tampering during the CI/CD process. Since it is impossible to rewrite a blockchain’s history, GOSH in general and AnyTree in particular give users an unprecedented level of Software Supply Chain Component trust, and Deep SBOM is a big reason why
Deep SBOM extends the SBOM surface to include all build environments. Other SBOM solutions only work with Artefacts, meaning they have no knowledge of build processes and cannot account for built process vulnerabilities
An artefact could be built with different compiler optimization options. For example, a C compiler optimization, as allowed by specifications, removes code that is used to perform checks to detect integer overflows. Or, an artefact could include a static link to a library with potential vulnerabilities (e.g.: “static linking SSH library”)
Integrating GOSH Builder with AnyTree can prove builds on a developer machine and a server (or a cloud) are identical
Solutions such as HashiCorp Vagrant deliver reproducibility by copying the whole development environment. But there is no guarantee that the developer machine is not compromised
GOSH achieves these same results with declarative build descriptions which include all dependencies within their environments and have full control over the build process within GOSH Builder
GOSH Builder isolates builds, only giving access to declared components
The resulting container can be fully validated versus sources and build environments with consistently reproducible results
An example of an integration would be: A developer can send a build description to the Cloud and validate that the result is exactly matching the description, and that the Cloud provider could not include anything into the build.
The hash mismatch between a container built by GOSH Build on the server and user machine’s build will mean probable compromise of a user environment, Making the Cloud solutions trustless from the developer’s point of view
We can make an analogy with poker: if you know what cards your opponent has, you have perfect visibility. However, if you do not know what cards your opponent has, you have to make assumptions, which reduces the quality of your decision-making; leads you to make approximate probability assumptions, and means you do not know if you can win or not until all your decisions have already been made. We use this example to illustrate how visibility is highly dependent on what is inside, as you can only speculate about what you cannot see. You do not have this problem with Deep SBOM, as it allows you to see strong relationships right from the beginning of the development process, meaning you can observe the parts and the whole much like a database of vulnerabilities.
Part III: Conclusion
The problem of an absolutely secure supply chain is generally unsolvable by maths, but the only technique that can be used, and GOSH’s solution to this problem, is to ensure visibility and integrity, and provide immutability and trustless tools — almost as in constant surveillance of — for your software supply chain. This is what AnyTree is about.
With AnyTree, developers can build images and distribute them across their network. Because AnyTree works with almost any package manager, user or server applications, developers use AnyTree without needing to change the way they distribute software, but still benefit from an array of security guarantees. They check their images with Deep SBOM and uses GOSH Build to safely build reproducible containers in an isolated environment. This allows them to distribute software for the host machine. If something goes wrong in any stage of the supply chain, any user can backtrack everything to the precise point where the error was introduced. This tool guarantees that every image is signed on GOSH and the integrity of every file. A software developer on GOSH, wanting to distribute his package, can create their container, and ship it to Docker Hub (AnyTree Packages can be downloaded from Docker Hub and the GOSH Docker Desktop Extension) — and the user, when installing, can verify this image is built on GOSH, signed on GOSH, by the author of the image.
AnyTree is the first software deployment system secured by a blockchain. With AnyTree all of the points of failure in the CI/CD process can be seen and verified, and AnyTree allows developers to clearly see every single back door they have in their code, and in the external code they use.
AnyTree utilises standard Docker Containers secured by GOSH Builder and is currently available as Beta on Linux and is coming soon to Mac and Windows. Try it now: https://gosh.sh/anytree
If you like this post and would like to read more: