What five years of Chainguard have taught us

The evolution of security practices has shifted from reactive symptom management to addressing the root cause of vulnerabilities. The core insight is that trusting external, unverified code and build systems poses a significant risk, as demonstrated by historical events like the SUBURST attack. This realization drove the creation of Chainguard, which focuses on building open-source infrastructure with verifiable security, emphasizing building securely from the source.
The organization's journey involved recognizing that traditional vulnerability response—like scanning—is insufficient symptom management. Instead, a proactive approach was adopted: ensuring builds are built openly from source, signed, and continuously patched to inherently reduce the vulnerability surface. This philosophy demands that security be integrated into the development workflow so that secure defaults become the easiest options for developers, rather than obstacles.
The progression of learning involves treating build systems as critical production environments, applying the same rigor in access control and hardening, and scaling these principles across complex distributed systems challenges. The future direction involves vertical integration to combine safe content with secure runtime execution, addressing the need for trust at machine speed amidst rapid development cycles involving AI-assisted coding.

* Ken Thompson published "Reflections on Trusting Trust" in 1984.
* The SUBURST attack involved attackers compromising a build system and shipping malware via a signed update.
* Founders spent years at Google working on open source infrastructure, including Knative, Tekton, Sigstore, SLSA, distroless, ko, kaniko, go-containerregistry, and minikube.
* The team observed that teams often pulled unverified code from public registries and treated security as a scanner report.
* A response to the SolarWinds attack required addressing the problem at the source: building open source from source, signing it, keeping it patched, and making security the easy default.
* The approach shifted from symptom management (scanning) to cause management by building artifacts built from source with only what is needed to run.
* Teams should treat build systems like production systems concerning access controls, monitoring, and hardening.
* The experience led to treating build systems with distributed systems problems like scheduling, throughput, failure handling, and consistency.
* The goal is to combine providing the safest content with providing the safest way to run it and code.

The narrative traces a powerful shift from theoretical understanding of trust in software to mandatory practical enforcement across the entire software supply chain. The initial catalyst was realizing that an absence of direct control over code creation creates inherent vulnerabilities, a concept proven by historical events like the SUBURST attack. The subsequent development of Chainguard reflects a systemic counter-response to this lack of trust, moving away from post-facto detection toward preventative architectural guarantees embedded in the build process itself.
A significant pattern emerges in the progression: recognizing that technical solutions (scanning) are insufficient when the underlying structural problem is unverified provenance and poor system design. The transition from "symptom management" to "cause management"—moving from scanning vulnerabilities to controlling the source artifact—is a pattern of necessary paradigm shifts when dealing with systemic risk. This mirrors historical shifts where understanding the root mechanism (Thompson's work) precedes effective intervention.
The implication for human agency is that security infrastructure cannot remain an add-on; it must be foundational, forcing developers to internalize the concept that operational integrity and security are inseparable from the source code itself. The focus on treating build systems like production systems reflects a necessary, almost authoritarian, restructuring of organizational trust within technical workflows. The ultimate trajectory points toward vertical integration—controlling the entire pipeline from source signing to runtime execution—as the only way to achieve machine-speed trust in an age where automated systems accelerate both capability and risk.
Bridge Questions: If building verifiable, secure artifacts is the goal, what organizational structures must change to enforce this shift across disparate development teams? How does the drive for full vertical integration balance the need for open source accessibility within a commercial product context? What are the long-term implications when trust mechanisms become deeply embedded at machine speed?