Adopt hardened containers without changing your pipelines, tooling, or environment

Today, we're announcing a batch of updates to Chainguard Containers that make it easier to run hardened images in your existing environment. A secure container only helps if it fits the stack you already run, from your RHEL-based pipelines to your FIPS requirements to your compliance tooling. Until now, those gaps have forced teams to choose between security and compatibility. These updates close them.

That includes first-party RPM support for RHEL 9 and RHEL 10 (in preview), new -full image tags that drop in without breaking your pipelines, a CMVP-validated Go Geomys FIPS image, Dependabot support for private cgr.dev registries, and flattened CycloneDX SBOMs your compliance tools can actually ingest.

Containers have become the dominant unit of deployment for modern software, and the build process itself has become as much of a liability as the runtime. What goes into the base image, which dependencies get pulled, and how the whole thing gets assembled are decisions with real security consequences. AI workloads, regulated infrastructure, and developer pipelines are converging on the same foundation. The organizations that get their AI readiness foundation right can move fast without accumulating risk. The ones that don't are managing inherited CVE debt at machine speed, chasing patch cycles, and hoping nothing critical slips through before the next quarterly update.

There's a right way to build containers: minimal by default, rebuilt from source continuously, cryptographically attested end-to-end, with provenance at every layer. Not as a feature you turn on, but as part of the architecture itself.

That's what Chainguard has always built with Chainguard Containers. Today, we're extending that foundation further into the enterprise environments where most production workloads actually run, and into the operational workflows that determine whether security gets adopted or quietly worked around. In a world where exploitation windows have turned negative and frontier models have found novel attack paths with low-severity vulnerabilities, it has never been more critical to build on top of a secure-by-default foundation.

Chainguard now runs where regulated workloads actually live

RHEL 9 and RHEL 10 RPM Support

For many enterprise teams, particularly in financial services, government, and regulated industries, the real blocker to adopting Chainguard has been that business applications are often distributed in RHEL’s package format, and internal tooling assumes RPM package management. That's a deep dependency, and it doesn't move quickly.

So, we built a metadata bridge that closes the RPM gap. 

Chainguard OS already ships most of the same core packages that RPMs depend upon, such as glibc, OpenSSL, and zlib, and all are built from upstream sources. The problem was that RPM's dependency resolver checks its own database, not the filesystem. In a Chainguard OS container image, those packages are tracked by APK, so the RPM database remains empty. Every dependency check fails even when the required shared library is sitting right there on disk.

Rather than converting packages to APKs or forcing customers to rebuild their RHEL-based pipelines, we built a metadata bridge that reads what APK already knows about installed packages and translates those capabilities into the RPM equivalents that RHEL-built packages expect to find — soname references, package-name capabilities, and versioned symbol sets. That translated metadata seeds the RPM database, and after that, rpm -i works normally. The original RPM artifact is untouched, while the packages underneath are Chainguard's, rebuilt from source continuously with full provenance and maintained under Chainguard's zero-CVE SLA.

This allows customers to install first-party RPM packages built for RHEL 9 and RHEL 10 directly into Chainguard Container images. If a required dependency is missing from the base image, the tooling identifies the corresponding Chainguard OS package, installs it, re-seeds the RPM database, and retries automatically.

To be clear, this is not a RHEL fork or a 1:1 binary-compatible replacement for stock RHEL. Where Chainguard OS's ABI surface matches RHEL's, as it does for the vast majority of standard library interfaces, this works as a drop-in replacement. Where it genuinely diverges, the system fails at install time rather than silently at runtime. For most enterprise workloads, it just works.

To request access to a preview of this capability, please sign up here.

Introducing -full tags

Moving to a hardened, minimal container image means leaving behind packages like debugging tools, utilities, and other extras that don't belong in a production image but have quietly become part of everyday developer workflows. That dependency is often what makes the migration feel challenging. Teams want the security benefits of a CVE-free image but aren't ready to untangle everything that relies on those extra packages.

The -full tag separates those two problems. It fully mirrors the upstream Docker Hub equivalent, which includes the same packages, entrypoint, environment variables, and user and group configuration. Mirroring in this way allows teams to move to a Chainguard image without changing their workflows. The CVEs are resolved immediately while the workflow migration proceeds on its own timeline.

The -full tag is an onboarding accelerant, not a destination. Once teams are running on Chainguard, the path to a minimal image is a deliberate migration step rather than a prerequisite for getting started. We’re offering -full tags for these 10 popular base and application images: python, node, nginx, go, redis, jdk, grafana, jre, prometheus, and postgres.

Native Geomys-based Go FIPS image  

Chainguard's FIPS coverage for Go workloads is expanding. Upstream Go has supported a native FIPS 140-3 module since Go 1.24, developed in partnership with Geomys, and that module has now completed CMVP validation (CMVP #5247). We ship this module in the go-geomys-fips image, which is now GA.

The new go-geomys-fips image gives teams a Go native Geomys-based FIPS image alongside Chainguard's existing OpenSSL-based Go FIPS image. Unlike upstream Go, which ships the Geomys module as opt-in, go-geomys-fips defaults to and hardens the validated module. This makes it impossible to compile binaries without FIPS crypto, and outright blocks broken and disallowed algorithms — including DES, RC4, DSA, and SHA-1 — in signatures. The image also uses a kernel-independent entropy source (CMVP ESV #E318), and the toolchain binary itself is FIPS-compiled, meaning TLS for module fetch and checksum verification uses FIPS crypto, making it appropriate for use inside FedRAMP boundaries. The image also includes a new go-fips-test tool to verify that go-based binaries use a FIPS-validated cryptographic module.

Chainguard will continue to support the existing OpenSSL-based go-fips image. Long-term, we will support multiple Go FIPS flavors, as we do with multiple Java flavors today. When any changes to existing images are planned, we'll communicate with advance notice through the Activity Center.

Custom Assembly now supports internal APK mirrors in private Beta

Custom Assembly lets teams extend Chainguard Containers with packages, environment variables, user accounts, and certificates while retaining Chainguard's SBOMs, signatures, and provenance attestations on every build.

Now, you can specify custom APK repository URLs in your Custom Assembly configuration. For organizations whose security policies prohibit production workloads from reaching external endpoints at runtime, this closes a meaningful gap. The customer-supplied URLs are written into /etc/apk/repositories in the final image, so any runtime package operations resolve to the organization's internal mirror rather than Chainguard's default endpoints. Build-time package resolution is unaffected as packages are always fetched from Chainguard's curated repositories during the build, preserving the supply chain boundary.

If you are interested in trying this feature, sign up here, and your account manager will reach out to add you to the private beta. 

Custom Certificates for Custom Assembly is now GA

Custom Certificate support for Custom Assembly, which launched in beta in December, is now generally available. Enterprise teams can now add PEM-encoded internal CA certificates directly to their image configuration via chainctl. Chainguard validates them, rejects private keys, appends them to the system trust bundle and Java truststores at build time, and includes them in the image's provenance attestation. For teams that have been rebuilding Chainguard Containers solely to inject certificates, that rebuild step is now gone.

Better compatibility with the tools you already use

Dependabot now works with private cgr.dev registries

Hardened images that never get updated quickly accumulate CVEs. Keeping image tags up to date in GitHub repositories has historically required manual attention or custom tooling for private cgr.dev images. Dependabot, despite being the natural fit, couldn't authenticate against our registry.

We've now resolved all registry-side compatibility issues, and Dependabot can now automatically authenticate, enumerate tags, and open pull requests to bump Docker image tags from cgr.dev with no custom tooling required.

Both are fixed. The registry now responds to non-Bearer auth with a 401 Www-Authenticate challenge, directing clients through the standard Bearer token exchange. Tag pagination returns a well-formed empty array on the final page. Dependabot can now automatically authenticate, enumerate tags, and open pull requests to bump Docker image tags from cgr.dev with no custom tooling required.

Flattened CycloneDX SBOMs

Chainguard Containers now ship an improved CycloneDX SBOM format, broadening compatibility with enterprise compliance tooling and making it easier for security and procurement teams to integrate container SBOMs into existing workflows, including those built on Mend SCA (formerly WhiteSource SCA).

The updated format enumerates all packages and subcomponents as a flat component list, with dependencies declared in the relationships section, enabling tools like Mend SCA to render a full graph view tracing which component came from which package. External references are also moved to the correct CycloneDX top-level section. All of this is delivered without modifying the underlying security posture.

All CycloneDX SBOMs are now delivered in this improved format. Users can download them directly from the Console or through chainctl, no new flags or tooling required.

The full picture

As the surface area and volume of code explode, engineering and security teams need to find standardization that doesn’t equate to friction. A hardened container image delivers value only if your RPM-based pipelines can adopt it, your FIPS requirements are met, and your compliance tooling can ingest the SBOM. This release removes those barriers, not by compromising on security posture, but by extending it into the environments and workflows where enterprise software actually runs.

Explore the Chainguard Containers catalog to see what's available, or talk to our team about running Chainguard in your environment.