Developer workflow for software supply-chain security is in high demand

In the early days of the internet when there were only millions of sites (compared with today’s 1.6 billion), transport layer security was not easy. Web developers could buy certificates for browsers, but they were expensive, hard to use and not very automated. We can all remember hitting sites without https configured and getting the security warning messages from our browsers.

SEE: Mobile device security policy (TechRepublic Premium)

Then Let’s Encrypt came along, made TLS free, simple and automated–and within a couple of years, most of the web was encrypted. Developers want to do the right thing … it just has to be easy and automatic.

Today we’re seeing another massive security challenge ahead for developers, where nothing is easy or automatic: software supply-chain security. Open-source projects and vendors are racing to fill in the gaps.

We secured production but forgot to secure build

Log4J and the question of how to lock down software supply-chain artifacts was initially oversimplified into hot takes about maintainer and contributor models being broken, as I’ve written. But it’s so much more complicated than that.

“The baseline has risen for application security and infrastructure security,” said Dan Lorenc, CEO and co-founder of Chainguard. “People aren’t reusing passwords everywhere. HTTPS is easy and showing up on every web site. We’re not sending passwords in clear text anymore. Attackers aren’t finding success with what they normally do, so they move to the path of lesser resistance, which is supply-chain attacks. If they’ve done a good job of protecting themselves–you can find a vendor they use, or an open source dependency, or a library and then pivot to all of their customers.”

Prior to Chainguard, Lorenc worked for nine years on the infrastructure behind Google Cloud Platform. So he has some (read: a lot of) familiarity with tackling this issue.

“Google’s internal security approach was amazing. They had to go through a multi-year process to create it, but they basically had a system where nobody could run any code without multiple people approving it, to really protect user data. At that time–in 2012 or 2013–developers really did not have root in production, and you needed multiple people to check everything.”

But as the cloud arrived and everyone started working on containers and Kubernetes, Lorenc observed that developers at large were building on laptops or Jenkins machines under desks instead of anything revealing a secure build environment.

“All of a sudden the state of the art was to buy a Mac Mini, expense it, then put it under your desk, install Jenkins, and then do the releases from there,” said Lorenc, who at that time was working on the Minikube project, which became the default way to run Kubernetes on a laptop. “I would put an 80 megabyte Go binary up on GitHub and everybody was downloading it and running it as root on their laptops, and that was frankly terrifying. And that led me down this rabbit hole of–how do we fix this?”

What’s missing is a root of trust for software artifacts

Lorenc met Chainguard co-founder Kim Lewandowski at Google, and they have both been approaching the software supply chain security problem through a series of open source projects that they co-created and co-maintain.

“The software development and deployment supply chain is quite complicated, with numerous threats along the source ➞ build ➞ publish workflow,” said Lewandowski, in a blog post describing the general lack of a toolchain for developers locking down software artifacts. “While point solutions do exist for some specific vulnerabilities, there is no comprehensive end-to-end framework that both defines how to mitigate threats across the software supply chain, and provides reasonable security guarantees.”

So, Lewandowski and Lorenc set out to solve the problem through open source. Supply Chain Levels for Software Artifacts (aka, SLSA, pronounced “salsa”), Sigstore, Tekton and their other open-source projects focus on various layers of an ultimate vision of zero trust security for software supply chain security–where every artifact can be verifiably traced back to the source code and hardware it was built on, and by whom.

Chainguard launches Enforce

Chainguard has brought these new roots of trust into its first commercial offering, called Enforce, which it launched today, less than five months after the company secured $5 million in seed funding led by Amplify Partners.

Enforce brings a curated set of policy definitions based on open-source projects like SLSA and the National Institute of Standards and Technology’s Secure Software Development Framework (SSDF) standards.

Enforce’s policy agent discovers what’s running in containers in the actual binary code itself, the container image. Developers can apply policies based on what the container image is, how it was built, and where it comes from. And continuous verification makes sure deployed container images stay in compliance with defined policies.

“We take this inverse approach where we look at what’s actually running rather than trying to block stuff at deployment time,” Lorenc said. “A lot of the metadata related to software supply chains changes over time. If you only look at pre-deployment, you’re missing 90% of the problem. Because just because something didn’t have any critical vulnerabilities when you first built and deployed it, that doesn’t mean it still doesn’t have any critical vulnerabilities three years later. So it’s really a continuous policy system approach, rather than just a deployment approach.

Busy times ahead for supply-chain security

This software supply-chain security landscape is very early, and it’s going to move very quickly. Last year the White House’s executive order on improving cybersecurity very explicitly called out the requirement for “a formal record containing the details and supply chain relationships of various components used in building software.”

We’ve spent decades building things in software and being obsessed with securing production, but then been building (too often) on un-patched Jenkins boxes sitting under someone’s desk that no one is looking after.

A new class of open-source projects and security vendors believe that your build system should be at least as secure as your production environment. And there will be a symbiotic relationship between open-source projects and guard-railed commercial offerings like Enforce where vendors package up a developer experience around this nuanced use case.

“Software supply chain security is pretty unique,” Lorenc said. “You’ve got a whole lot of different types of attacks that can target a whole lot of different points in the software life cycle. You can’t just take one piece of security software, turn it on and get protected from everything. I think we’re going to see a pattern of a bunch of different open source frameworks like SLSA and SSDF being leveraged together to keep evolving how we lock down software supply chain security.”

Disclosure: I work for MongoDB but the views expressed herein are mine alone.