What five years of Chainguard have taught us

What five years of Chainguard have taught us - View all articles Matt Moore Co-founder and CTO Chainguard Matt Moore Co-founder and CTO In theory, there is no difference between theory and practice. In practice, there is. That's my favorite quote, and it's the best way I know to explain why Chainguard exists. In 1984, Ken Thompson published "Reflections on Trusting Trust." He showed that a compromised compiler could plant a backdoor in every program it built, including future versions of itself, without leaving a trace in the source code. The takeaway was unsettling: you can't fully trust code you didn't build yourself, and nobody builds all of it themselves. It has become one of the most famous papers in computer science. Then the SUBURST attack on Solarwinds turned theory into practice. Attackers compromised a build system and shipped malware to thousands of organizations inside a signed, legitimate update. Thompson had described exactly this 36 years earlier. In practice, it took the SUNBURST attack for anyone to care. I often say that if we'd started Chainguard a year earlier, building exactly the same product, we would have struggled to raise money. Nobody cared. Then, almost overnight, everyone did. Five years later, with malware surging and Mythos-class models industrializing exploitation, nobody can afford not to care. Why we started Chainguard Before Chainguard, much of our founding team spent years at Google working on open source infrastructure: Knative, Tekton, Sigstore, SLSA, distroless, ko, kaniko, go-containerregistry, and minikube. This infrastructure makes up a lot of the plumbing people use to build and ship containers today. Working on that plumbing from the inside taught us two things: the world runs on open source, and almost nobody can vouch for the open source they run. Teams were pulling unverified code from public registries, shipping images packed with CVEs, and treating security as a scanner report instead of a serious consideration into how software is built. When SolarWinds hit, the world was suddenly facing a problem we knew how to solve. We also knew it would be an enormous amount of work. This shit is hard. We stepped up anyway. The answer was deceptively simple: fix it at the source. Build open source from source, sign it, keep it patched, and make the secure default the easy default. What five years have taught us Treat the disease, not the symptoms. The industry's default answer to vulnerabilities was more scanning. Scan the image, triage the findings, file tickets, argue about which CVEs really matter, and do it all again next week. That's symptom management. A scanner tells you what's wrong, but it doesn't fix anything. We went after the cause instead. That's why we built Wolfi, and why Chainguard Containers are built from source with only what's needed to run. When you rebuild everything continuously and ship less, the CVE count drops to zero and stays there. The best triage process is having nothing to triage. Make the secure path the easy path. Developers won't adopt security that slows them down, and they shouldn't have to. If the secure option is harder to use, it loses, no matter how safe it is. So we obsess over making Chainguard a drop-in: same tools, same workflows, far fewer vulnerabilities. Security that people route around isn't security. Treat your build systems like production systems. (Then watch them become production systems.) Early on, one of our favorite lines was that teams should treat their build systems like production systems. We meant it from a security standpoint: give your build infrastructure the same access controls, monitoring, and hardening you'd give anything customer-facing, because it's exactly what an attacker wants. SolarWinds proved the point. Five years in, that line has picked up a second meaning. We now run our factory at such a scale, across containers, libraries, CI/CD, and more, that our build systems hit the same distributed systems problems you'd expect in a large production service: scheduling, throughput, failure handling, and consistency. We ended up taking our own advice more literally than we planned, and it's been one of the most fun engineering problems I've worked on. Where we're going We started by assembling the key tools and concepts to give people the safest source of open source content anywhere. That work keeps expanding to more languages, more artifact types, and more layers of the stack. Producing safe content also puts us in an unusual position: we control the entire production pipeline, from source to signed artifact. So the next question is what we can do with that. How do we bring the pieces together so they work exceptionally well together? Can we go beyond giving you the safest content and also give you the safest way to run it, and to run your own code, too? I really admire what Apple has done with full vertical integration. When you build every layer, you can make them fit together in ways that nobody assembling parts from different vendors can. We build everything in our stack, and I want to find out how far that can take us. AI agents and coding tools are writing code and pulling in dependencies faster than any human can review them, and attackers have the same tools. Trust has to work at machine speed. Thank you To the customers who bet on us early, the open source community whose work we build on every day, and the Chainguard employees who made the last five years happen: thank you. Five years ago, trusting trust was a problem most people only knew as a theory. Now it's a practical one for everyone. We're not done solving it, and the next five years will matter even more. Share this article Related articles