Early December marked the one-year anniversary of the Log4j security meltdown. Ever since, the software world has been on a dead sprint to ensure it would never happen again. We’re finally seeing some traction as the missing links in software supply chain security begin to get filled in.
Log4j was a crippling event for many organizations that struggled to understand whether and where they were even running the popular open source logging utility in their environments. But Log4j also forced the industry come to grips with the transitive nature of software supply chain exploits and just how easy it is for exploits to leap across software dependencies. It was not a fun way for security teams to end 2021.
Nor did security vendors cover themselves in glory. Initially, we saw a rash of opportunistic security software marketers rush to position their wares as direct solutions. But according to Dan Lorenc, CEO and founder of software supply chain security startup Chainguard, “Most scanners use package databases to see what packages are installed inside of containers. Software installed outside of these systems aren’t readily identifiable, making them invisible to scanners.”
In other words, security vendors were selling thoughts and prayers, not real solutions.
Not everyone was so vacuous in their response. This software supply chain security challenge is connected very specifically to open source. The reality is that modern applications are built mostly with open source frameworks of somewhat unknown security provenance. You just can’t have an enterprise solution that secures all of open source—it doesn’t work in that direction. The answer, it would seem, needs to come from the open source community itself. In 2022, it did.
A massive community response
There has been an incredible amount of activity around software supply chain security, and tons of examples of the open source community circling the wagons in 2022.
Some of it is welcome but largely hollow public signaling from officials, like the White House’s executive order to secure the software supply chain and the U.S. Senate’s Securing Open Source Software Act of 2022. This is nice, but software security isn’t about public proclamations. Fortunately, what’s really been happening this past year is a lot of hustle to arm developers with the toolchains to address supply chain security farther left in the software development life cycle.
Not surprisingly, the Linux Foundation and Cloud Native Computing Foundation have been heavily involved in making this happen in key open source projects. For example, the SPDX SBOM format has made its way into major platforms like Kubernetes. The Open Source Security Foundation has more than 100 members and many millions of dollars in funding for more standards and tools. Memory-safe languages like Rust are supported by the Linux kernel to ward off a whole class of software artifact–related vulnerabilities.
Possibly the most notable individual technology that has been on a tear during the past year is Sigstore, the code-signing tool that was born at Google and Red Hat and has become the de facto “wax seal” now embedded into open source software registries and toolchains. Kubernetes, npm, and PyPi are among the platforms and registries that have adopted Sigstore as their signing standards. Importantly, all of these Sigstore signatures go into a public transparency log, which is an important new heartbeat for the security ecosystem to start connecting the dots between software signing, software bills of materials (SBOMs), and the entire software supply chain security provenance toolchain.
A familiar jump from open source to commercial
Anyone paying attention to open source for the past 20 years—or even the past two—will not be surprised to see commercial interests start to flourish around these popular open source technologies. As has become standard, that commercial success is usually spelled c-l-o-u-d. Here’s one prominent example: On December 8, 2022, Chainguard, the company whose founders cocreated Sigstore while at Google, released Chainguard Enforce Signing, which enables customers to use Sigstore-as-a-service to generate digital signatures for software artifacts inside their own organization using their individual identities and one-time-use keys.
This new capability helps organizations ensure the integrity of container images, code commits, and other artifacts with private signatures that can be validated at any point an artifact needs to be verified. It also allows a dividing line where open source software artifacts are signed in the open in a public transparency log; however, enterprises can sign their own software with the same flow, but with private versions that aren’t in the public log. Chainguard’s path is similar to GitHub: Developers can make unlimited public repositories but must pay for private team repositories.
Where is all this going?
It’s anyone’s guess what major developments in software supply chain security we’ll be talking about this time next year, but there’s a lot of reasons to believe this will remain one of the fastest evolving and most exciting areas in security (and that security will remain one of the most important areas in software). Much has been done to improve software security; much more remains.
Chainguard CEO and Sigstore cocreator Dan Lorenc is the first to admit how far there is to go, particularly around SBOMs where there’s a lot of white space between theory and reality for developers. If developers don’t have easy methods to build security into software artifacts early in the software development life cycle, he jokes, the result is “guess-BOMs.”
Lorenc points to the software signing made possible by Sigstore and the overall bubbling up of major projects being championed by open source bodies (industry and government alike). He see it as evidence that much of the power to solve this software supply chain security challenge is being put where it belongs: in the hands of developers with the right tools.
Copyright © 2022 IDG Communications, Inc.