.png)
Key takeaways
Open source container images are publicly available base and application images built from open source software, such as the official nginx, postgres, and python images on Docker Hub. They are production-ready only when someone actively tracks and remediates the vulnerabilities they carry. By default, that someone is you, not the image publisher.
That is the gap this guide closes. Most teams adopt a public image because it works on the first pull, then discover months later that the same image now reports dozens of unpatched CVEs no one is assigned to fix. The fix is not to abandon open source. It is to source the same software from images that are built and maintained for production.
This article covers who is on the hook for image CVEs, what separates a production-ready image from a convenient one, and how to adopt hardened images in CI/CD with minimal disruption.
You own the CVEs in every third-party container image you deploy, even the ones your team never built. Docker Hub publishers ship a snapshot; they do not patch it on your behalf or notify you when a package inside it becomes exploitable. The moment that image runs in your cluster, its vulnerabilities are your operational and audit risk.
NIST SP 800-190 section 3.1.1 names image vulnerabilities as a primary container risk, and section 4.1.1 places the responsibility to keep images updated and remediate known vulnerabilities on the organization running the workload. A public registry has no contractual obligation to you. There is no SLA on a free docker pull.
This is why scanning frequency rarely correlates with safety. A team can scan daily and still carry a backlog, because the image arrived with 50-plus pre-existing CVEs that no patch cadence was ever going to clear. The CISA Known Exploited Vulnerabilities catalog makes the stakes concrete: when a CVE inside your base image lands on that list, the clock is already running and the responsibility is already yours.
The CVE delta between a standard public image and a hardened equivalent is large and consistent. Minimus is a hardened container image platform that builds images from upstream source with only the packages an application needs to run. Across its gallery, the average CVE reduction versus public equivalents is 98%, per Minimus platform data, with a documented Go image going from 179 CVEs to 1.
The table below uses representative Minimus platform averages for common runtimes and data stores rather than image-specific measurements. Exact counts vary by image, tag, and scan date, so treat these figures as illustrative rather than a scorecard. Live per-image counts sit on the Minimus nginx image, postgres image, and python image pages.
The point of these deltas is not which vendor wins a feature grid. It is that the public-image CVEs are the ones you would otherwise be triaging by hand. For the full side-by-side, see the Docker Hub vs Minimus comparison, and for the counting methodology behind these figures, see the post on near-zero-CVE container images.
A hardened container image includes the exact packages required to run your application and excludes everything else, including the shell, package manager, and compilers. That exclusion is the security mechanism, not a side effect. Fewer packages mean fewer CVEs and a smaller attack surface for anything that gets a foothold.
This is also the answer to the most common objection: that stripping an image breaks builds. It does not, because what gets removed is build-time and debug tooling, not runtime dependencies. Your nginx still serves; your postgres still accepts connections. What disappears is the apt, bash, and curl an attacker relies on for enumeration and lateral movement after an initial compromise, the post-exploitation kit described across MITRE ATT&CK container techniques.
In practice, the package that breaks a swap is often a debug or init script someone added years ago rather than a true runtime requirement. Find those before you cut over. For the underlying theory, the posts on hardened container images and how minimal base images reduce real risk are the best starting points, and the deep dive into what's inside your nginx image shows exactly which components a standard image carries that the application never invokes.
Minimus compiles each image from upstream source inside a controlled pipeline with provenance tracking, rather than layering on top of an existing public image. Every actively maintained version is rebuilt daily from the freshest available packages, so version tags stay stable while the digest underneath reflects the current patch level. Build triggers are tied to formal upstream releases, not to a fixed schedule that lags real fixes.
Each build ships a cryptographically signed SBOM enumerating every package inside it, plus SLSA Level 3 build attestations that teams can verify in their own CI/CD using Sigstore and Cosign. That moves image trust from scanning after the fact to verifying provenance before deploy. Qualified open source projects can get these images free through the Minimus Open Source Program. Minimus’s Trust Center commits to remediating critical and high severity vulnerabilities within 2 calendar days of an upstream fix becoming available.
For residual CVEs in packages that must be present, Minimus tracks them and reports Mean Time to CVE (MTTC), a Minimus metric for how long an image stays clean between disclosures. The full mechanics are in the Minimus build approach and the Minimus platform overview.
Match each image to the runtime your service actually executes, not to the broadest base you can find. A typical multi-service stack of a web tier, a database, and an application runtime maps cleanly onto three hardened images: nginx or a similar ingress, postgres, and the language runtime such as python or node. Pick the narrowest image that still contains your real dependencies.
The edge cases are predictable. A service that shells out to a system binary at runtime, generates code on the fly, or relies on a package manager during startup needs that dependency declared explicitly rather than assumed from a fat base image. Audit for those before migrating.
A common approach is to map images per service during a sprint rather than swapping the whole stack at once, because it isolates any runtime surprise to a single deploy. Platform engineers tend to own this mapping across services, while developers usually validate the runtime dependencies for their own service. Both roles work from the same image catalog.
Adopting a hardened image is a one-line change to your Dockerfile, not a pipeline rewrite. You repoint the FROM instruction at the hardened equivalent and keep the rest of your build, registry, and deploy steps intact.
# Before: standard public base
FROM nginx:1.29
# After: hardened drop-in replacement
# Authenticate to the Minimus registry (reg.mini.dev) with a token first
FROM reg.mini.dev/nginx:1.29
Your existing scan and verification stages then run against the new image. Because each Minimus image is signed with Sigstore, you can add a verification gate that fails the build if the signature does not validate against the Minimus signing identity:
# GitHub Actions: verify the Minimus image signature before deploy
- name: Verify image signature with cosign
run: |
cosign verify \
--certificate-oidc-issuer=https://accounts.google.com \
--certificate-identity=minimus-images-sa@prod-375107.iam.gserviceaccount.com \
reg.mini.dev/nginx:1.29 | jq
Pull the image into your own registry or mirror it to an air-gapped one, and the workflow your team already uses does not change. The exact signature and SBOM attestation commands, including how to verify the signed SBOM, live in the Minimus docs on verifying images and SBOMs with Cosign. For a worked migration and a CI/CD reference build, see migrating from public base images to hardened images and the post on zero-CVE container images in your pipeline.
Open source images are production-ready when their vulnerabilities are owned and maintained, and by default that ownership is yours. Sourcing the same software from images built from source, rebuilt daily, and shipped with a signed SBOM moves that burden off your backlog without changing the open source you already run. The adoption cost is a one-line FROM change and a verification gate. To see current CVE counts per image, browse the gallery at images.minimus.io or get started.
Open source container images are safe in production when their CVEs are actively tracked and remediated. The software itself is not the risk; unpatched packages in a static public image are. Sourcing images that are rebuilt from source and shipped with a signed SBOM keeps the same open source software production-ready.
The organization deploying the image is responsible. NIST SP 800-190 section 4.1.1 (image vulnerability countermeasures) puts remediation on the team running the workload, and public registries provide no remediation SLA on a free pull. The publisher ships a snapshot; you own what happens after.
Hardened images remove build-time and debug tooling such as the shell and package manager, not the runtime dependencies your application executes. Builds break only when a script relied on a tool that was never a true runtime requirement, which is why auditing for shell and package-manager calls before migrating is the key step.
Repoint the Dockerfile FROM line at the hardened equivalent on the Minimus registry (reg.mini.dev) and keep every other build, scan, and deploy step. Add a cosign verify gate, with the Minimus certificate identity and OIDC issuer flags, to check the image signature, then pull or mirror the image into your existing registry.
.svg)
.svg)
.svg)
.svg)
