Official Go Docker Image vs CleanStart Hardened Go Image

This comparison focuses on the official Docker Hub Go image (golang:1.26.5) because it is one of the most widely used base images for building Go applications.

If you're building Go applications with Docker, there's a good chance your Dockerfile starts with the official Go image from Docker Hub.

It's a trusted starting point for thousands of developers. But before that image becomes part of your application, it's worth asking a simple question:

What exactly are you bringing into your software supply chain?

To answer that, we compared the official golang:1.26.5 Docker image with the equivalent CleanStart Go image.

Both images were analyzed using Docker Scout with the same scanning methodology to compare their software footprint, vulnerability profile, and software supply chain metadata.

Comparison Baseline

Side-by-Side Comparison

The results below compare both images using the same Go runtime (1.26.5), making this a like-for-like evaluation of their software composition and security posture.

The biggest difference wasn't the Go runtime, it was everything surrounding it. The official image contained more than five times as many installed packages and executable binaries, resulting in a significantly larger software footprint.

What the Scan Revealed

1. Over Five Times as Many Installed Packages

The official golang:1.26.5 image contains 207 installed packages, while the CleanStart image contains 39.

Every installed package becomes part of your software inventory. More packages mean more dependencies to track, monitor, update, and patch throughout the lifecycle of your application.

That's 168 fewer packages included in the CleanStart image, resulting in a significantly smaller software footprint.

2. More Than Five Times as Many Executables

The official Go image includes 455 executable binaries, compared to 81 in the CleanStart image.

Not every executable introduces risk, but every additional binary expands the software footprint inside the container. Production images generally benefit from including only what the application actually requires, reducing operational complexity and potential attack surface.

If you'd like to understand how executable count contributes to attack surface, read our guide on Attack Surface Reduction in Containers: Measuring What Really Matters.

3. 1,267 Known Vulnerabilities vs Zero Vulnerabilities

Docker Scout reported:

• 18 Critical 
• 103 High 
• 421 Medium 
• 686 Low 

for a total of 1,267 known vulnerabilities in the official Go image at the time of analysis.

The equivalent CleanStart Go image reported zero known CVEs.

The important takeaway isn't simply the vulnerability count. Every identified vulnerability eventually requires investigation, prioritization, patching, exception handling, or formal risk acceptance. Starting with fewer known vulnerabilities reduces that operational burden before an application is ever deployed.

4. Same Go Runtime. Different Software Foundation.

Both images include Go 1.26.5.

From a developer's perspective, you're building applications on the same language runtime.

The difference lies in everything surrounding that runtime:

• The number of installed packages 
• The number of executable binaries 
• The overall image size 
• The vulnerability profile 

This makes the comparison a true apple-to-apple evaluation, showing how two images built for the same purpose can differ significantly in their software composition.

5. Supply Chain Trust Goes Beyond an SBOM

Both images provide an SBOM, making it possible to inventory the software components contained within each image.

However, an SBOM tells you what is inside an image. It doesn't tell you how the image was built or whether its origin can be independently verified.

The CleanStart image also includes:

• SLSA-aligned provenance 
• Sigstore signatures 

These capabilities help answer questions that vulnerability scanners alone cannot:

• Where did this image originate? 
• How was it built? 
• Can its provenance be independently verified
• Has the image been cryptographically signed? 

As software supply chain security evolves, understanding what's inside an image is only part of the story. Being able to verify where it came from and how it was built is becoming equally important.

Conclusion

At first glance, both images appear to offer the same thing: Go 1.26.5.

But once you look inside, the differences become clear.

Compared to the official Docker Hub image, the CleanStart Go image contains:

• 57% smaller image size (297.9 MB vs. 129.1 MB) 
• 81% fewer installed packages (207 vs. 39) 
• 82% fewer executable binaries (455 vs. 81) 
• Zero known CVEs at the time of analysis (compared to 1,267) 
• SLSA-aligned provenance and Sigstore signatures to support software supply chain verification 

The purpose of this comparison isn't to suggest that every package or executable is inherently a risk. Rather, it's to highlight that every additional software component becomes part of your software supply chain and contributes to the ongoing effort required to inventory, monitor, patch, and verify what you deploy.

Whether your priority is reducing attack surface, simplifying vulnerability management, or strengthening software supply chain security, it's worth asking a simple question before choosing a base image: What exactly am I bringing into my software supply chain?

Try the CleanStart Community Images

Curious how your own applications compare?

Pull the equivalent CleanStart Community Image, scan it with Docker Scout, and compare the results in your own environment.

The Community Images are freely available for popular languages and runtimes and are built with a minimal software footprint, near-zero known vulnerabilities at release, SBOMs, SLSA-aligned provenance, and Sigstore signatures.

Explore the Community Images → images.cleanstart.com

Continue the Investigation

If you found this comparison useful, you may also enjoy these technical deep dives:

• Attack Surface Reduction in Containers: Measuring What Really Matters – Learn how package count, executables, and image composition influence container attack surface.
• Why SBOMs Alone Don't Establish Container Trust – Understand the difference between inventory and verification.
• Software Supply Chain Security: A Technical Imperative – Explore why provenance, signatures, and reproducible builds are becoming essential for modern software delivery.