The Day we Started to Protect DevOps with Blockchain

I still remember February 2018 very well. Many people were in a really bad mood when it came to Blockchain or Distributed Ledger Technology (DLT), mainly because the price of most cryptocurrencies made a nose dive and the Disillusionment started.

Funny enough, that was also the time, when my co-founder Moshe Bar (he became famous as the co-founder of XenSource and Qumranet) had some very interesting discussions how we can solve a real big DevOps-related issue.

We wanted to give digital objects a globally unique and meaningful identity without changing or appending something. Achieving Integrity and Trust for any digital asset.

If you want to see our projects (free for open source and non-commercial projects) before reading the full story:

Some background

So far, people either thought about checksum for files, source code or container images and best-case to use digital certificates to sign these files (if the file type was supported). While the checksum calculation using sha256 or sha512 is great for the digital fingerprint, digital certificates are not really made to use for any digital asset you can find. Last but not least, digital certificates are definitely not made for the agile world.

Quick one - what happens if you revoke a digital certificate:

1. all digital objects signed using this digital certificate are revoked
2. depending on the OS, Application or execution engine, warnings are shown for objects with revoked signatures
3. sometimes, binaries with revoked signatures can't be opened anymore

But more important, when do you revoke a certificate?

1. you lost the private key
2. someone stole your private key
3. you don't trust an digital asset anymore you signed

And here comes the real issue - if you would start signing hundreds or thousands of digital assets, you don't want to revoke your certificate just because of one or two you don't trust anymore. That also means, most certificates will never be revoked even if they are lost, stolen or untrusted.

To sign a digital object that has a revoked certificate with a new valid certificate you need to have access to it and redistribute it. Not just a huge effort - its sometimes impossible. Another reason why revocation is more of a nice idea than a powerful action to regain trust.

That makes digital certificates unfit for the solution we were about to build.

Here comes the Blockchain

In 2018 most people looked the other way when it came to Blockchain (mainly because of the price drop in Cryptocurrencies). We figured, that Blockchain was exactly the technology we needed to achieve our goal of global digital asset identity and trust - without becoming part of the "shady" certificate authority industry.

We moved ahead, founded , assembled a team and starting coding from day 1.

Distributed Ledger Technology

When digging into DLT, you quickly realize that many parts are still experimental and the existing tooling is in its early days. Leveraging public blockchains has some major disadvantages, high latency and the use of volatile crypto-currencies are just 2 of them.

Our requirements:

• no crypto-currency or tokens: As we expected loads of digital assets being written to the Blockchain, no-fee transactions were a absolute must
• no private Blockchain: We didn't want to go into a private Blockchain direction either, as our data required to be public accessible by just connecting to the Blockchain itself
• no hosted Blockchain: the last thing we wanted was a lock-in from day one and blockchain data migration ... well, long story
• available talent and tooling: going to exotic also means that developer are much harder to find and most tooling needs to be developed as well
• always on: from the start

Long story short: we decided to go for a consortium blockchain based on Ethereum ()

Zero Trust Consortium

Of course you need to start somewhere, so we set up our testnet internally without a consortium, to play around, research the required smart contracts and create the initial architecture. We also approached different companies to start the consortium with - to run a Blockchain for the software industry, by the software industry.

To our surprise our Consortium Blockchain idea was of great interest for many companies and in January 2019 we had already set up the Zero Trust Consortium with the Mainnet distributed across 12 initial members that run their own Parity Ethereum nodes. 9 months later, we just crossed the 30 member count.

The Zero Trust Consortium (ZTC) is headquartered in Switzerland with off-chain governance in place for new members and runs its own operations, independently from any member. Zero Downtime, No Hardforks, Fully managed. Every software company is welcome to join, run a node or become a contributing member.

Let's get back to DevOps and some basics

As the foundation for our solution was covered with the ZTC platform, we could completely focus on developing the solution to be released as .

When speaking about DevOps, basically a ton of topics are put into that bucket. Procedures, tools, automation, build pipelines, handling and storage of source code, microservices, container, ... the list can go on forever.

But the most important parts from a digital asset perspective are:

• Source Code (code repositories)
• artifacts (CI/CD, automation)
• files (configuration, definition, description, documentation)
• container (images, layer)

Our goal from the beginning was to support all of these, without touching them and without disrupting the automation in any way. Of course the integration should be easy to use, easy to integrate and fit for the modern age.

We named the process of creating a digital asset identity with a user identity notarization and the process of integrity and trust level verification authentication.

Of course before something can the authenticated it needs to be notarized by someone on the platform.

Process of CodeNotary notarization

1. calculating a sha256 checksum
2. getting files or object attributes
3. writing the object checksum to the Ethereum-technology-based blockchain including the trust level using the user identity (private key)
4. adding object attributes on a blockchain-protected relational database (CodeNotary backend)
5. success is only returned, when all data has successfully been written to the Blockchain

This example shows the notarization of a Prometheus configuration file, but it can be any artefact, a github repo, a docker image or a local directory.

If you want to either unsupport (i. e. because a newer version has been released and you want to unsupport the older versions) or untrust (in case you found a flaw, issue or just don't like the object anymore).

That way the status on the Blockchain changes as well and can immediately be checked from anywhere in the world. I'll get into that later.

vcn unsupport prometheus.yml

vcn untrust prometheus.yml

Let's also publicly notarize a very common docker container image:

docker pull ubuntu

vcn n -p docker://ubuntu:latest

Important - unlike digital code signing the digital asset is never changed or touched

Process of CodeNotary authentication

While Notarization is the most important part to get digital assets notarized with the unique identity, a trust level given by the signing user, its important to know that anyone in the world is now able to authenticate the very same digital asset.

1. calculating a sha256 checksum
2. querying the object checksum on the Ethereum-technology-based blockchain (either in general, only for a certain user or if a member of a given organization)
3. Success: You get the digital asset trust level and metadata back
4. Unknown: the digital asset has not been notarized yet

Important: No data except the unique checksum is ever uploaded. It not just saves bandwidth, it provides privacy as well.

Coming back to the notarized prometheus.yaml file, there are a couple of ways how you can authenticate.

Using the vcn command line:

vcn a prometheus.yaml

Remember the last notarization action was to unsupport the file, therefore we get an error as well. The error is especially helpful, when you integrate vcn into any automation or script.

Authenticating the docker image

vcn a docker://ubuntu:latest

But there are more ways to authenticate notarized objects:

• CodeNotary website:
• Javascript:
• Maven:
• Kubernetes:

Btw. we're currently working on a full blown API, so it gets even easier to integrate.

Dashboard

Whatever you do, it can be checked on the Dashboard. If you provide and maintain non-commercial Open Source projects, you get all features for free.

Full transparency on the Blockchain

Don't just take our word for it. You can check the Blockchain yourself following this video:

• Blockchain Explorer:
• CodeNotary Smart Contract Decoder: o

Quick install

Get started within a few minutes.

When you are on a command line, you can simply download the vcn CodeNotary version and start using it.

more documentation is on the GitHub Readme of the vcn project: