Base images are the largest single source of container vulnerability findings, and most teams inherit hundreds of CVEs from packages their applications never use. Hardened container image catalogues sell a different starting point: minimal images with no shell or package manager where possible, rebuilt continuously from patched sources, and shipped with SBOMs, signatures and provenance. The category has grown quickly, and offerings differ sharply in catalogue breadth, patch commitments, compatibility and what "zero CVE" actually means. This vendor-neutral buyer's guide helps platform engineers, DevSecOps leads and vulnerability managers compare catalogues and run a fair proof of concept. The engineering side, including multi-stage builds, distroless debugging and digest pinning, is in the Hardened and Minimal Base Images Guide; runtime protection is in the Container Security Guide.
Key takeaways
- Freshness is the product, not size. A minimal image that is rebuilt slowly accumulates CVEs like any other. Buy a patch commitment, measured from upstream fix to published image, and verify it.
- "Zero CVE" is a scanner result on a date. Ask which scanners, which feeds and how unfixed or disputed findings are handled, and expect VEX statements rather than silence.
- Catalogue fit decides adoption. If the images your teams need (language runtimes, databases, proxies, AI frameworks) are missing, developers will fall back to public images.
- Verify everything you pull. Signatures, SBOMs and SLSA provenance only help if your pipeline or admission controller checks them.
- FIPS claims need a certificate number. FIPS 140-2 validations moved to the CMVP Historical list on 21 September 2026 (NIST still allows their use in existing systems); new work should rely on FIPS 140-3 validated modules.
Define requirements
- Image inventory: list the base images and application images in use today, by language runtime, OS family and version, and rank by deployment count. This sets the catalogue coverage you need.
- C library and compatibility: glibc or musl, and any native extensions, agents or vendor software that are certified only on a particular distribution.
- Vulnerability targets: the remediation timelines in your vulnerability management policy, for example for CISA Known Exploited Vulnerabilities and critical findings, which the supplier's patch commitment must beat. See the CISA KEV Catalogue Guide.
- Regulated workloads: whether you need FIPS 140-3 validated cryptographic modules (NIST SP 800-53 SC-13), STIG-hardened images or other sector baselines, and for which images.
- Supply chain evidence: the SBOM format (SPDX or CycloneDX), VEX, signatures and provenance your SBOM and admission tooling can consume. See the SBOM Guide and VEX Guide.
- Distribution: whether images must be mirrored into your own registry, air-gapped, or pulled from the supplier's registry, and how pull credentials are managed.
- Customisation: whether teams need to add packages, certificates or agents, and whether the supplier builds customised images or you extend theirs.
Capability areas
| Area | What good looks like | Weak version to avoid |
|---|---|---|
| Catalogue breadth | Language runtimes, web servers, databases, message brokers, proxies, CI tooling and AI frameworks, with several supported versions each | A small set of showcase images; long tail left to public images |
| Minimisation | Runtime variants with no shell or package manager; separate development variants for builds and debugging | "Slim" images that still carry shells, compilers and unused libraries |
| Patch commitment | Written SLA from upstream fix to published image, by severity, with continuous rebuilds and history you can audit | Best effort rebuilds; no measurable commitment |
| Vulnerability transparency | Scan results published per image and tag; VEX for not-affected and unfixed findings; clear advisory feed | A "zero CVE" badge with no method or data |
| SBOM and provenance | SBOM per image in SPDX or CycloneDX, signed SLSA build provenance, reproducible or declarative builds | SBOMs generated after the fact by scanning the finished image only |
| Signing | Every image and attestation signed; documented verification identities and keys; works with your admission policy | Signatures on some tags only, or verification that needs the supplier's proprietary tool |
| FIPS and compliance variants | FIPS variants using modules with active FIPS 140-3 certificates, named in documentation; STIG or CIS hardening evidence where offered | "FIPS compliant" or "FIPS ready" with no certificate number |
| Compatibility and support | Clear version lifecycle, migration guides, support for the CPU architectures you run, responsive support | Silent tag removals; versions dropped without notice |
| Delivery and access | Mirroring to your registry, digest-stable tags, scoped pull tokens, audit logs | Shared long-lived pull credentials for every team |
SLSA's build track is a useful yardstick for provenance claims: Build L2 requires hosted build infrastructure and signed provenance that consumers validate, and Build L3 adds isolation between builds and keeps signing secrets out of reach of user-defined build steps. Ask which level a supplier claims, against which version of the specification. See the SLSA and Build Provenance Guide.
Evaluation criteria
| Criterion | What to test | Evidence to request | Suggested weight |
|---|---|---|---|
| Catalogue coverage | Map your top 20 base images to the catalogue | Catalogue list with versions and architectures | 20% |
| Patch speed | Pick recent upstream fixes and measure time to published image | Contractual SLA; 12 months of rebuild and advisory history | 20% |
| Vulnerability results | Scan images with your own scanners, not only the supplier's | Scanner and feed used for claims; VEX documents | 15% |
| Compatibility | Rebuild and run real applications, including native extensions | Migration guides; known incompatibilities | 15% |
| Supply chain evidence | Verify signatures, SBOMs and provenance in your pipeline and admission controller | Verification documentation; SLSA level claimed | 15% |
| FIPS and compliance | Check named modules against the CMVP list | Certificate numbers; STIG or benchmark evidence | 5% |
| Commercial terms | Pricing model against your image and node count; exit terms | Price per image, per pull or per node; rights to keep using pulled images | 10% |
The pull credentials and registry tokens that CI pipelines and clusters use to fetch hardened images are non-human identities with write-adjacent reach into production. Scope them per environment, store them in a secrets manager and rotate them. A compromised registry account lets an attacker plant a malicious image (ATT&CK T1525 Implant Internal Image). See the Container Registry Security Guide.
Questions to ask vendors
- What is your written patch SLA by severity, measured from which event, and what remedies apply if you miss it?
- Show the rebuild history and time to fix for three recent high-profile CVEs in images we use.
- Which scanners and vulnerability feeds support your CVE claims, and how do you publish not-affected and unfixed findings?
- Which SBOM formats do you provide, how are they generated, and are they signed and attached to the image?
- Which SLSA build level and specification version do your builds meet, and can we verify provenance with open tooling?
- For FIPS variants, which cryptographic modules and CMVP certificate numbers are used, and what happens when a certificate moves to historical status?
- How long is each image version supported, and how much notice do you give before a version or tag is removed?
- Can we mirror images into our registry and keep using them if the contract ends?
Red flags
- "Zero CVE" claims with no named scanner, date or published scan data.
- FIPS claims without certificate numbers, or relying on FIPS 140-2 modules for new deployments.
- No written patch SLA, or one measured from the supplier's own triage date rather than the upstream fix.
- SBOMs that disagree with your own scan of the same image.
- Signatures that can only be verified with a proprietary client.
- Terms that stop you running already pulled images after cancellation.
Proof of concept
- Choose five representative services covering different runtimes, including one with native dependencies.
- Rebase each onto the candidate images using multi-stage builds, and run your test suites.
- Scan before and after with your own scanners; record total, critical and fixable findings.
- Enforce signature and provenance verification in a non-production admission controller in audit mode, then enforce.
- Track rebuilds over the POC weeks and measure time from upstream fix to new image for any CVE that appears.
- Validate FIPS variants by checking module certificates on the CMVP list.
- Test the rollback: revert one service to its previous base image by digest and confirm it deploys cleanly.
How NHI Mgmt Group can help
We provide independent software supply chain and identity security advisory, including container image strategy and product evaluation. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Hardened and Minimal Base Images Guide · Container Security Guide · Sigstore Guide · FIPS 140-3 and Cryptographic Module Validation Guide · Kubernetes Admission Control Guide