A two-line move to Red Hat Hardened Images cut one Go container by 84%

Red Hat has published a compact migration example for its Hardened Images service: replace the builder and runtime base-image lines in a Go application’s Dockerfile, then automate rebuilds as updated bases arrive. In Red Hat’s account, the change reduced the application image from 218 MB to 35 MB—an 84% drop.

The useful part is not the headline number alone. The example links image minimization to a continuing rebuild process rather than treating a small image as a one-time security result.

What the pattern changes

The original application carried components it did not need, including a shell, package manager and curl. Red Hat’s replacement uses a Go builder image and a static runtime image from a catalog that the company says spans roughly 100 runtimes and services, including Go, Python, Node.js, Java, Ruby, PostgreSQL and Nginx.

That removes unused software from the final artifact. Red Hat says the images are produced with SLSA Level 3 supply-chain controls, signed with cosign and accompanied by a verifiable software bill of materials. Those properties give a platform team evidence to check; they do not eliminate the need to verify provenance and compatibility in its own pipeline.

The operational step matters more

The worked example adds a daily workflow that pulls an updated hardened base, rebuilds the application and redeploys it. Red Hat says this keeps the running workload no more than 24 hours behind a patched base in this setup. The company reports a current median of 18 hours for its image pipeline to deliver vulnerability fixes, against a service-level objective of delivering 80% within seven days.

Those are vendor-reported pipeline figures, not a universal remediation time. An application can still carry vulnerabilities in its own dependencies, and an automatic base-image rebuild can introduce a regression. Teams adopting the pattern should retain tests, signature verification, SBOM inspection and promotion controls between rebuild and production.

What platform teams should try

A sensible first trial is a statically linked service whose runtime requirements are easy to enumerate. Compare the old and new images for size, package inventory and startup behavior; verify the cosign signature and SBOM; then run the normal integration and policy gates before promotion.

The larger lesson is straightforward: changing the base image shrinks today’s attack surface, while a tested rebuild-and-promotion loop determines how quickly tomorrow’s fixes reach a workload. Red Hat’s two-line Dockerfile example makes the first step unusually small, but the surrounding automation is the part that turns it into a supply-chain practice.