Announcing Chainguard container images for Go 1.27

Go 1.27 is here, and Chainguard has used this release to make choosing and running a Go image simpler and more flexible. This includes a new go-openssl-fips image that lets you pick your FIPS-validated cryptographic module at deploy time instead of build time. We have simplified our offering to three images: go, go-fips, and go-openssl-fips. Each of these images contains all the great features new to Go 1.27 – they differ only in how they approach cryptography. Go is for teams that want the smallest image and don’t need FIPS-validated cryptography, go-fips is for teams that want to use Go-native FIPS-validated cryptography, and go-openssl-fips is for teams that need both Go-native and OpenSSL-based FIPS-validated cryptography. Both FIPS images are post-quantum-ready for CNSA 2.0 ahead of the 2027 deadline, and each image ships with a new -slim tag.

Four older images (go-openssl, go-msft-fips, go-geomys-fips, and go-slim) will stay on Go 1.26 through its end of life on August 10, 2027, and will not receive updates to Go 1.27. If you’re a current customer using one of these new images, you will need to migrate to one of the three Go 1.27 images with a configuration change to maintain the existing behavior on Go 1.27.

Choosing your Go 1.27 image

We are offering three container images with Go 1.27: 

• go: The standard Go image: upstream Go with Chainguard hardening and the latest cryptography built in by default. This image is for teams that don't need FIPS and want the smallest image.

• go-fips: The pure Go image with FIPS-validated cryptography. This contains the Go Cryptographic Module – a native, pure-Go FIPS validated module that produces self-contained FIPS binaries with no dependency on a system OpenSSL. This image is for teams with new FIPS deployments that want a single portable, validated module everywhere they run. 

• go-openssl-fips: The flexible Go image that allows runtime configuration of FIPS-validated cryptography. By default, this image uses the host's OpenSSL FIPS provider (i.e., the Chainguard FIPS Provider for OpenSSL on Chainguard hosts), and the Go Cryptographic Module as a fallback. The choice between them is configurable at deploy time. This image is for teams running multiple workflows across mixed environments, or teams that want to continue using Chainguard’s FIPS-validated OpenSSL provider to avoid changing CMVP numbers.

Impact to FedRAMP ATO

On Go 1.27, the go-fips image now defaults to the Go Cryptographic Module instead of OpenSSL (as was the case on versions 1.26 and earlier). This is a change to the validated module that can impact your FedRAMP authorization to operate (ATO). If you need to maintain the existing OpenSSL-based FIPS cryptography, we recommend either staying on Go 1.26 or moving to the new go-openssl-fips image. In this image, OpenSSL is preferred by default, so on a FIPS-capable host, the binary performs its cryptography in the same validated module as before: the same provider, certificate, and algorithms as in version 1.26. Please refer to the migration table below to ensure your CMVP number is maintained as intended. 

This multi-module runtime support also enables customers to use Chainguard FIPS Provider OpenSSL, their own validated modules, and rebranded cryptographic modules from OpenSSL Corporation and Geomys in their Go deployments.

A -slim tag on every image, and MD5 configuration

Every Go image on 1.27, FIPS and non-FIPS, also ships a -slim tag: CGO_ENABLED=0 by default, with no bash, git, or GCC. One build pipeline can produce all release artifacts across all architectures and operating systems, and use all cryptographic modules. Access to MD5 is now a runtime policy choice, and no longer a separate image or package. Every FIPS image allows it under fips140=on for non-security purposes (no HMAC, no digital signatures), and it is always blocked under fips140=only.

PQC Ready for CNSA 2.0 and 2027

Chainguard's FIPS hardening applies to Go's TLS stack, with the Commercial National Security Algorithm Suite (CNSA) 2.0 cipher suites and key exchange used by default when PQC algorithms are available at runtime, and CNSA 1.0 settings otherwise. The defaults close that gap:

• ML-KEM-1024 is the preferred PQC key exchange group, ahead of hybrids

• P-384 is the preferred non-PQC key exchange group for TLSv1.2

• AES-256 is preferred over AES-128

• ML-DSA certificates supported with upcoming modules

If you need to stay on CNSA 1.0, please set GODEBUG=tlsmlkem=0, which removes post-quantum key exchange from the offer and leaves P-384 and AES-256 in front, without the need to recompile binaries.

Starting January 1, 2027, new National Security Systems acquisitions are expected to support CNSA 2.0 algorithms by default. Chainguard delivers a single artifact that can be either CNSA 1.0, the current requirement, or CNSA 2.0, the requirement in 2027. As ML-KEM-1024 is the default key exchange group, a Go service built on this toolchain already negotiates post-quantum key exchange, which protects today's traffic against harvest-now, decrypt-later.

CNSA 2.0 also requires TLS to use ML-DSA certificates. The upcoming Chainguard FIPS provider for OpenSSL v3.6 and Go Cryptographic Modules v1.26 has ML-DSA support at runtime. Both modules are currently in coordination at NIST CMVP and are expected to be validated soon. 

Choose your FIPS module at runtime

Customers can now use our go-openssl-fips image to choose which FIPS-validated cryptographic module their software uses at deployment. Until now, choosing a FIPS 140-3 cryptographic module for go meant choosing a toolchain. Go-msft-fips routed cryptography to the host’s OpenSSL FIPS provider, and go-geomys-fips used the Go Cryptographic module. Customers picked one and compiled against it, leading to binaries with the cryptographic module fixed at compile time. That build-time choice becomes a problem at deploy time: A team that compiles for OpenSSL can't run on a host without a FIPS-compliant OpenSSL. A team that wants to evaluate the Go Cryptographic Module has to rebuild, re-sign, and re-release everything before it can even try. And a team supporting both needs two pipelines producing two artifacts from the same source.

Our new Go FIPS toolchain lets you ship a single artifact and select the validated module after the build at the point of deployment. Because this module is a runtime choice, one build now does what used to take several builds: it runs wherever you deploy, cross-compiles from a single command, keeps your validated module and FedRAMP authorization intact, and is ready for CNSO 2.0, all without recompilation. This is a new feature available starting with v1.27 tags. Our go-openssl-fips image now includes both the Chainguard FIPS Provider for OpenSSL and the upstream-included Geomys-validated cryptographic modules. Existing functionality with Go 1.26 and earlier remains unchanged and is supported until end-of-life, so customers can migrate on their own schedule. 

Go-openssl-fips: compile for any OS without a cross-compiler

The go-openssl-fips toolchain is based on Microsoft's Go build. It implements a nocgo-based dynamic linker. As a result, it enables the creation of portable native binaries without needing a C cross-compilation toolchain at build time.

• Cross-compilation is one command again. GOOS=linux GOARCH=arm64 go build works from an amd64 workstation, and every other GOOS and GOARCH pair works the same way, with no cross-compiler or target sysroot to install per target.

• Binaries no longer inherit the build host's glibc. Nothing links against libcrypto at build time, so a binary built on a current distribution runs on considerably older ones.

Portable native binaries can be cross-compiled for IBM Z (s390x) mainframes, IBM POWER, Microsoft Windows, and Apple macOS. These all come with native FIPS-validated cryptography via system-installed OpenSSL, CNG, and CryptoSystem, or a fallback to the Geomys module.

Moving to Go 1.27

If you're on an older Go image with version 1.26 (go-openssl, go-slim, go-geomys-fips, go-msft-fips, go, or go-fips), you can continue using your existing images through Go 1.26’s EOL Grace Period, which ends August 10, 2027. You can keep using these images until you're ready to migrate to a 1.27 image. Depending on what image you currently use and your FIPS requirements, the migration path can vary: 

In Conclusion

We’re excited to release Go 1.27 support on three images. Based on your use case and FIPS-validated cryptography requirements, we have an image that meets your needs. For the current set of validated cryptographic modules, see the Chainguard FIPS commitment page, and follow the FIPS knowledge base article for notification when a module changes.

If you have questions, our team is at support.chainguard.dev.