merkely devops change management Artifact Binary Provenance
merkely devops change management Artifact Binary Provenance

How to secure your software supply chain with Artifact Binary Provenance

In Merkely, we use Artifact Binary Provenance as the foundation for our audit trails. Artifact Binary Provenance is a fancy term, but the idea behind it is really quite simple. All it means is that we can identify the software we have running in production. Let’s take a closer look 👀

How should we identify software?

There’s lots of ways to identify software. In our industry we’ve tried different approaches to version-numbers like semantic versioning and release names. These are human-centered approaches that involve applying a name to a specific piece of software.

This approach is called version labeling

The downside of this approach is that it is fallible. Any label can be applied to any software package, so it’s easy to see how mistakes can be made. For example, the version number could be incorrectly bumped, or errors in copying and distributing software could cause a misapplication of identity.

Version labeling also creates a security threat. A malicious actor could label their software in a way that makes a system believe it is running qualified software, but is instead running compromised software.

For compliance and security reasons we need a more reliable approach.

Content Addressable Storage

In high security environments we need a tamper-proof identity scheme. In plain talk, if the software changes we want it to have a different identity.

Luckily, this is a solved problem in computer science. The solution is Content Addressable Storage.

How this works is really simple. Instead of using a label to define software identity, you use the cryptographic hash of the software itself.

This means that if a single byte in the software changes it will have a different identity.

Can’t I just use the git commit SHA to identify the software?

Git commits define a content addressable snapshot of the source code (and its history). If you are distributing the source repo as your artifact this could be a valid method of identity.

However, in most cases software is not distributed as source but rather as binaries (typically through compilation, packaging, or Docker images). This translation process is often non-reproducible or nondeterministic, removing a hard trace from source to binary. In other words, the binary package could be labelled with a source commit that is invalid.

For this reason we use a Secure Hash Algorithm (SHA) to identify the binary.

Storing the provenance

Now that we have a method for identifying software, wouldn’t it be great if we could look this up on demand from our DevOps tools?

A compliance System of Record provides a secure database to store claims to the identity (we have a strong opinion on what that should be 😇). When we create a binary in our secure CI build process we store the identity information in a journal.

Artifact Binary Provenance process Merkely

As each binary progresses through the value stream you can record evidence against it such as:

  • Source commit
  • Build url
  • Test results
  • Security analysis
  • Deployments
  • Approvals

And the information is as easy to look up as it is to store. Our deployment processes can perform risk controls to ensure deployments are based on known approved binaries and verified processes. This is why we believe Artifact Binary Provenance is the basis for any compliance-based DevOps approach. It makes it impossible to qualify one piece of software and deploy another.

What about the humans?

Does this mean SemVer is dead? That you shouldn’t use git SHAs to identify your software? Not at all!

These are very useful ways for humans to navigate identity through version control and CI systems. However, since they are fallible, we still need the primary key of identity to be the content-addressable storage, linked to the labels. Labels are for humans and SHAs are for machines.

Top Articles

How to do Continuous Delivery in your ITIL framework?

Continuous Compliance: A DevOps culture

We’re going to DevOpsDays Denmark 🎉

Published January 13, 2022 in
Mike Long
Mike Long

Subscribe to The Merkely Meteor Newsletter for all the latest on regulated DevOps, features, news and events

Merkely is committed to protecting and respecting your privacy. You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our Privacy Policy.
Subscribe to the Merkely Meteor

More posts in technology

How to do Continuous Delivery in your ITIL framework?

Key takeaways ITIL change management framework doesn’t work for frequent software releases That’s a problem because regulated teams want continuous delivery By automating change management they can release software as standard changes Introduction There are quite a lot of articles out there on this topic, usually trying to score for SEO, that promise to show you how to do this without actually ever getting there. But it can be done and in this piece I will explain how.

Continuous Compliance: A DevOps culture

Imagine your developers are the world’s fastest relay team 🏃 When it comes to build, test, and qualify they get round the running track faster than anyone else. Unfortunately for them the finishing line is hidden somewhere outside the stadium. Welcome to regulated DevOps How did they get to be running this impossible race? Well, better tools and working practices have meant a dramatic shift from annual software releases to a world where teams have the ability to deploy multiple times every day.

Why ITIL Change Management doesn’t work for DevOps teams

Are you trying to do DevOps under regulation? If so, you’ll know the pain of change management. In this article we’ll look at how delivering software with DevOps is incompatible with old school ways of managing change with ITIL and how you can automate your change management process with a DevOps approach. As regulated industries speed up their DevOps processes they find that managing software releases with ITIL tickets and change meetings just doesn’t scale.

Subscribe to the Merkely Meteor newsletter for all the latest on regulated DevOps, how to’s, features, news and events

Merkely is committed to protecting and respecting your privacy. You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our Privacy Policy.
Subscribe to the Merkely Meteor