An independent assessment validates industry-leading build integrity for Chainguard Containers. Every customer receives the benefit automatically.
Software supply chain security has a trust problem.
It’s easy for a software vendor to say that its artifacts are built securely. It is much harder to produce credible evidence showing where an artifact came from, how it was built, and what prevented that build from being tampered with.
Today, we are proud to announce that the build and release system for Chainguard Containers has been independently assessed by Coalfire and found to meet the requirements of SLSA Build Level 3.
This is an industry-leading milestone. More importantly, it independently validates a principle that has guided Chainguard from the beginning: Security should be built into the software our customers consume, delivered continuously, and verifiable, not simply asserted.
What SLSA Build Level 3 means
SLSA is a cross-industry framework for protecting the integrity of software as it moves from source code through build systems and into the hands of consumers.
The current SLSA Build Track culminates at Level 3. At this level, software must be produced by a hardened build platform with strong controls that isolate individual builds, prevent one build from influencing another, and keep provenance-signing secrets outside the reach of user-controlled build steps. The resulting provenance provides verifiable information about which platform built an artifact, which process it used, and which inputs influenced the build.
A provenance record is only trustworthy when an attacker cannot alter or forge it. A build is only isolated when malicious code cannot persist into the next build, poison a shared cache, access another workload, or steal the credentials used to sign trusted artifacts.
That’s why Chainguard builds run in dedicated, ephemeral environments and why signing occurs separately from the build workers themselves. Our build system’s trusted control plane generates the provenance; the code running inside a build can’t rewrite that history or access the signing material needed to impersonate a trusted Chainguard build. Chainguard also produces build provenance and a signed software bill of materials (SBOM) for each release.
Going beyond “trust us”
Meeting the technical requirements is the foundation. Proving that we meet them is the differentiator.
SLSA provides a rigorous framework, but its ecosystem lacks a universal certification program. Rather than asking customers to accept our own assessment of our security, we invited an independent third party to examine the systems, controls, and evidence behind our claim.
Coalfire’s assessment evaluated the build and release practices used to produce Chainguard container images, including the controls around build isolation, change management, provenance generation, and the protection of sensitive signing material.
The result gives customers meaningful, independent evidence that the systems producing the artifacts they rely on operate as we say they do.
Security claims are easy to make. Providing evidence is harder. We chose to provide the evidence.
Every customer benefits automatically
The best part of this milestone is what our customers need to do to receive its benefits:
Nothing.
The controls assessed by Coalfire are part of the systems Chainguard uses to produce its container images. That means every customer consuming the images covered by the assessment benefits from the same hardened build environments, protected signing process, and automatically generated provenance.
Customers do not need to become experts in build-system isolation or maintain their own hardened software factory. We do that work upstream and deliver the result as part of the product.
For teams that want to inspect or enforce these guarantees directly, Chainguard’s signed provenance and SBOM attestations can be retrieved and verified using standard tools such as Cosign. That verification is available for additional assurance and policy enforcement, but it is not required to benefit from the underlying build protections.
Built for the attacks the industry is facing now
This milestone arrives at a critical time. In April 2026, GitHub described an increasingly common pattern in open source supply-chain attacks: Attackers compromise CI/CD workflows, exfiltrate API keys and publishing credentials, and then use those credentials to distribute malicious packages from attacker-controlled systems. The malicious packages can then steal more credentials and spread the compromise into additional projects.
SLSA Build Level 3 directly raises the bar against several parts of that attack chain.
Build isolation helps prevent malicious activity in one build from persisting into or influencing another. Separating signing secrets from build workers limits an attacker’s ability to turn a compromised build job into a trusted signing operation. Tamper-resistant provenance binds an artifact to the expected builder and build process, enabling detection and rejection of artifacts produced outside the authorized pipeline.
That does not make SLSA a silver bullet. Build provenance does not determine whether source code itself is free of malicious logic. It doesn’t replace source review, eliminate dependency risk, or make runtime security unnecessary. SLSA is explicit about those boundaries.
What it provides is a critical integrity layer: stronger assurance that the artifact delivered to a customer is the artifact that the trusted system was expected to build, and that it was not silently substituted or altered along the way.
That layer belongs alongside secure source management, minimal artifacts, rapid vulnerability remediation, signed SBOMs, and ongoing monitoring. This is defense-in-depth, delivered by default.
The hard security work should happen upstream
Modern organizations depend on enormous amounts of software they did not write. They shouldn’t have to reproduce the same build-system security work independently for every container image they consume.
Our responsibility is to do that hard work once, do it rigorously, and distribute the resulting protection at scale.
With independently assessed SLSA Build Level 3, Chainguard customers gain stronger build integrity and more credible evidence of the software they deploy, without adding another security project to their backlog.
That is what secure by default should mean.
Share this article
Related articles
- security
The keyv and cacheable npm Supply Chain Attack: Inside the Mini Shai-Hulud Campaign
Quincy Castro, CISO
- security
Why AI-assisted attacks made software supply chain security its own category
Anushka Iyer, Product Marketing Manager
- security
Why zero CVEs matters in mobile airgapped deployments
Mike Barretta, Senior Manager, Solutions Engineering
- security
Mitigating WordPress attacks with containers
Adrian Mouat, Staff DevRel Engineer
- security
Responding to the Five Eyes guidance on AI and cyber risk
Chris Carty, Enterprise Solutions Engineer
- security
AsyncAPI supply chain compromise: npm packages backdoored via GitHub Actions "pwn request" (July 2026)
Quincy Castro, CISO