Software developers have a supply chain security problem

Log4j was the bucket of cold water that woke up most developers to their software supply chain security problem. 

We’ve spent decades in software building things and obsessing over our production environment. But we’re building on unpatched Jenkins boxes sitting under someone’s desk. We spend all this time protecting our runtimes, then deploy to them using amateur tooling. 

Our build environments aren’t nearly as secure as our production environments.

That’s what led to a whole lot of high-profile attacks in the last 12 months, from SolarWinds, to the Codecov attack, to the Travis CI secrets leak. We’ve gotten so good at protecting our infrastructure that attackers looked for an easier way in, and found it in the doorways we’ve left open in the supply chain.

Can’t get in through the perimeter security? Just find an open source dependency, or a library, and get in that way. Then pivot to all of the customers. This is the modern software supply chain hack.

We need roots of trust for software

We have roots of trust for people today. We have two-factor authentication, we have identification systems. These are things to vouch for a person’s identity. And hardware has the same thing. We have encryption keys. We have hardware we can trust hasn’t been tampered with when it boots up.

Even as internet users we have roots of trust. We have URIs, URNs, and URLs—effectively the namespaces on the internet that connect the identities, names, and locations of sites we are browsing. SSL certificates tell our browsers that sites are secure. DNS firewalls sit between the user’s recursive resolvers to make sure our cache isn’t being loaded with bad requests. All of this is happening behind the scenes, and has been incredibly effective in supporting billions of internet users for decades.

But we don’t have this for software artifacts today. 

Developers trust too much implicitly

Take an event as commonplace as installing Prometheus (a popular open source observability project) from the Cloud Native Computing Foundation (CNCF) artifact hub. If you do your Helm install and then look at all the images that get pulled and start running your cluster, you see many container images that end up running from a simple installation. Developers are entrusting a whole bunch of things to a whole bunch of different people and systems. Every single one of these could be tampered with or attacked, or could be malicious.