What is Chainguard? Rethinking Software Supply Chain Security
Author: Frazer Brown
Release Date: 09/10/2026
Modern software development depends heavily on open-source software. From container images and programming languages to libraries and application dependencies, developers rely on components created and maintained outside their own organisations.
That reliance brings enormous benefits in terms of speed, innovation and reuse. But it also introduces a fundamental security challenge: how do you know that the software you’re building with is secure?
This is where Chainguard comes in.
As a software supply chain security company, Chainguard provides a trusted source of open-source software, rebuilding commonly used software components from verified source code in a highly secure, automated environment.
In this first instalment of our Chainguard series, we look at what Chainguard is, why traditional approaches to vulnerability management can create a constant cycle of patching and remediation, and how a secure-by-design approach can help organisations reduce that burden.
The challenge with open-source software
Open-source software has transformed modern software development. Developers can use established frameworks, libraries and components rather than building everything from scratch, helping organisations deliver applications faster.
However, the same components can introduce security risks.
Public container registries and package repositories contain huge numbers of software components, and organisations don’t always have complete visibility into how those components were built, who maintains them, or what security controls were applied during the build process.
A commonly used open-source image may also contain far more software than an application actually needs. Each additional component can increase the potential attack surface and introduce vulnerabilities that security teams subsequently have to identify, investigate and remediate.
The result can be a familiar cycle:
Pull → Scan → Triage → Patch → Repeat
Developers pull an image or dependency into their environment. Security tools identify vulnerabilities, many of which may require investigation to determine their actual impact. Developers and security teams then spend time triaging and patching the issues before the process starts again with the next release.
For organisations using large numbers of open-source components, this can consume significant amounts of engineering time.
Moving beyond the CVE patching cycle
Traditional vulnerability management largely focuses on identifying vulnerabilities after software has entered the development environment. Chainguard takes a different approach.
Rather than simply finding and patching vulnerabilities in existing software, Chainguard aims to address the problem at the source by building software from verified source code in what it calls the Chainguard Factory. The Factory is a highly secure, automated build environment designed around software supply chain security. Components are rebuilt from source and accompanied by information about what went into them, including software bills of materials (SBOMs). This changes the starting point for developers.
Instead of beginning with a generic public image and then discovering hundreds of vulnerabilities through scanning, teams can start with hardened, minimal images designed to contain only what is required. As Chainguard puts it, the goal isn’t simply to shift security left. It’s to start left.
Smaller, hardened container images
Container images are a good example of where this approach can make a difference. A conventional image may contain package managers, shells and other components that aren’t required for an application to run. While these can be useful during development, they can also increase the image’s size and attack surface. Chainguard’s container images are designed to be minimal by removing unnecessary components.
One example highlighted in our Chainguard Explained video series is Node.js. In the comparison, the Chainguard Node.js image contains significantly fewer vulnerabilities than the alternative image, while also being considerably smaller. The principle is straightforward: if a component isn’t needed, removing it means there is less software to secure.
Chainguard maintains a large catalogue of hardened container images covering common base images, applications and technologies, alongside specialised options for areas such as AI and machine learning. The images are also cryptographically signed and include software bills of materials, providing greater visibility into their contents and provenance.
Securing software dependencies
Containers are only one part of the software supply chain.
Modern applications can depend on hundreds or even thousands of third-party libraries. A compromised dependency can therefore create a significant security risk even when the application's own code is secure.
This has become an increasingly important concern as attackers have targeted language-level dependencies and package ecosystems.
Rather than relying on pre-built binaries from public repositories, Chainguard rebuilds supported libraries from verified source code within its controlled build environment.
The result is a set of drop-in alternatives for commonly used open-source dependencies.
For developers, this can mean continuing to use familiar languages and frameworks without fundamentally changing how their applications are written. For security teams, it provides greater confidence in where those dependencies came from and how they were built.
Why provenance matters
Knowing that a component has a known and verifiable origin is an increasingly important part of software supply chain security.
It's not enough to know that an application uses a particular version of a library. Organisations also need to understand where that software came from and whether it has been altered or compromised somewhere along the way.
By controlling the build process from source through to distribution, Chainguard aims to provide verifiable provenance for the software it supplies.
This is particularly important when organisations need to demonstrate that their software components meet internal security requirements or provide evidence during audits.
The role of SBOMs
Software bills of materials are another important part of the picture.
Modern applications are built from large numbers of open-source and third-party components. Without visibility into those components, organisations can struggle to determine whether they are affected when a new vulnerability is discovered.
An SBOM provides a structured inventory of the software components contained within an application or image.
Chainguard provides SBOMs with its container images, giving security and development teams greater visibility into what they are deploying.
Combined with verified provenance and minimal images, this provides a clearer picture of the software supply chain rather than treating an application as a single black box.
From reacting to vulnerabilities to reducing them
The fundamental idea behind Chainguard is relatively simple: security shouldn't always have to begin with finding problems after the software has been built.
By rebuilding open-source software from verified source code, removing unnecessary components and providing information about provenance and composition, Chainguard aims to make the software supply chain more secure from the outset.
For development teams, that can mean less time spent investigating and patching vulnerabilities.
For security teams, it can mean fewer alerts and greater confidence in the software entering the environment.
And for organisations, it provides a way to approach software supply chain security as a preventative discipline rather than an endless cycle of remediation.
This is only the starting point. In the rest of our Chainguard series, we'll look more closely at the platform, including the Chainguard Console, container images, libraries, Helm charts, OS packages and integrations, as well as newer capabilities across the platform.