Fast Go CVE Remediation: Reducing CVE Risk With Hardened Container Images

At Minimus, We provide OCI container base hardened images with significantly fewer, often zero, CVEs compared to widely used images on Docker Hub.

We achieve this through two core practices:

1. Keeping our images as minimal as possible, since fewer packages reduce the attack surface and the number of potential CVEs. (Minimus images have 97% fewer CVEs on average than public images.)
   
2. Maintaining a low mean time to remediate (MTTR) for any vulnerabilities that are discovered. Critical and High severity CVEs are fixed in Minimus images within 48 hours.

In this article, I’ll focus on how Minimus remediates Go-related CVEs quickly and systematically, and what makes that speed possible. 

‍

How Minimus Keeps MTTR Low

Fast Detection

Keeping MTTR low starts with fast detection, which we accomplish by regularly scanning every package in our packages universe, which contains over 30,000 open packages. When a new CVE is detected, Minimus issues an advisory that appears in your console and triggers alerts.

‍

Images Built from Source

We have a strict requirement to build all projects that make up our packages from source. While this may sound trivial, building from source comes with a lot of operational complexity. Most projects are far from trivial to build and require ongoing maintenance, as their build processes and build-time or run-time dependencies may change significantly over time.

Building projects from source provides us with two key advantages:

1. It allows us to apply build-time configurations that enable safer and more secure usage, as some projects expose security-related options during build.
   
2. When a CVE is discovered, it gives us greater flexibility in how we remediate it. Since we aren't stuck waiting for upstream release cycles, we have the flexibility to remediate quickly and precisely.

‍

Automation to Support Remediation Speed

To support even faster remediation, we put in the effort to make the CVE remediation process in Minimus mostly automatic. To enable this, our infrastructure continuously monitors multiple vulnerability databases, including NVD, GHSA, MITRE, the Go Vulnerability Database, and more.

For each vulnerability, we build a complete picture by correlating information across these sources. This helps us fully understand the issue and determine the best way to fix it.

‍

How We Categorize and Remediate Go Vulnerabilities

Now, let’s dive into Go vulnerabilities. We categorize Go vulnerabilities in our packages into three types:

1. Vulnerabilities in the project itself that we are packaging.
   
2. Vulnerabilities in one of the project’s Go module dependencies.
   
3. Vulnerabilities in the Go toolchain used to build the project.

Each type of vulnerability requires a different remediation approach.

‍

Type 1: Vulnerabilities in the Project Itself

Minimus is designed to achieve fast updateability. We constantly monitor all the projects we package for new releases. In some cases, the only way to remediate a CVE is to wait for an upstream fix. Once a fix is available, we aim to apply it as quickly as possible. (This is true not only for Go vulnerabilities.)

‍

Type 2: Vulnerabilities in Module Dependencies

When a vulnerability is discovered in one of a project’s module dependencies, we may actively try to “bump” it. This involves querying multiple vulnerability databases, cross-checking the information to find the correct patched version, updating the dependency in the project’s go.mod file, and then rebuilding and testing the project.

‍

Type 3: Vulnerabilities in the Go Toolchain

This type differs, because the Go version used to build our packages is itself packaged in our OS. Remediation requires identifying the first patched version of the Go toolchain, ensuring that our OS provides this version (or a newer one), and then rebuilding and testing the affected packages.

A Real-World Example: Remediating Go CVEs With Minimus

Let’s take a look at a vulnerability in our grafana-11.4 package.

CVE-2025-22872 (NVD link) was first published in GitHub’s advisory database as GHSA-vvgc-356p-c3xw (GitHub link) on April 16, 2025.

The issue was found in the golang.org/x/net module, which Grafana v0.36 was using at the time. The first patched version of the module was v0.38. 

To fix the vulnerability, we bumped the dependency in Grafana’s go.mod file to v0.38, rebuilt the package, and ran our tests to ensure everything worked as expected.

This is a good example of how we actively track and remediate vulnerabilities in module dependencies, keeping our hardened images secure and up to date.

Automated Detection and Correlation

In this case, our scanner first flagged the package as vulnerable to CVE-2025-22872.
Our remediation process then correlated it with the GHSA-vvgc-356p-c3xw record. The information in the GHSA advisory provided enough details for us to determine the appropriate fix.

‍

New Image Build

A new build of the package was triggered, which included updating the relevant module to version 0.38 in the project’s go.mod file. Once the package was built and tested, it was published and re-scanned. Since the re-scan no longer reported the vulnerability, it was considered resolved.

Finally, a new image build was triggered for the affected Minimus image, ensuring that the vulnerability was fully eliminated from our image.

‍

End-to-End Remediation Time

From the time the CVE was published, it took less than 12 hours for it to be fully remediated from our images. That includes detection, correlation across advisory sources, dependency updates, rebuilding, testing, re-scanning, and publishing a new image.

This timeline is possible because detection, source builds, and rebuild automation are tightly integrated into our packaging workflow.

‍

Go from Detection to Resolution in Hours With Minimus

Go CVEs are inevitable. Slow remediation is not.

At Minimus, low MTTR is engineered into the system. We build from source, control our OS and toolchain, continuously monitor multiple vulnerability databases, and automate rebuilds and re-scans. That is how we fix critical and high CVEs within 48 hours, often much faster.

The Grafana example shows this in action: Detect, correlate, bump the vulnerable module, rebuild, test, publish, and trigger a new image. End to end, in under 12 hours.

Minimal images reduce exposure. Source builds give us control. Automation delivers speed.

If you are running Go in production, the real question is not whether vulnerabilities will appear. It is how quickly you can eliminate them. Schedule a demo to see how Minimus reduces CVE exposure and accelerates remediation in your environment.