
Container image vendor selection is one of the few platform decisions that quietly shapes every workload, every audit cycle, and every incident response for years. Two vendors come up most often when teams shop for alternatives to public Docker Hub images: RapidFort and Minimus.
Both cut CVEs out of container deployments. They get there through opposite technical approaches. This article maps the architectural differences, names the tradeoffs of each approach, and gives a decision framework drawn from migrations I have reviewed in regulated and commercial environments.
Minimus and RapidFort are container image security vendors that reduce CVEs in container deployments through opposite architectural approaches. Minimus builds minimal container images directly from upstream source code on a 48-hour critical-CVE rebuild SLA. RapidFort optimizes existing public LTS images by profiling runtime usage and stripping unused components.
Minimus is a hardened container image platform. It publishes 1,000+ minimal images built from upstream source, ships each with a SLSA Build L3 attestation, a cryptographically signed SBOM, and published VEX, and rebuilds against a 48-hour SLA on critical and high CVEs.
RapidFort is a software supply chain security platform. It maintains 25,000+ Curated Near-Zero CVE images on stock LTS bases (Ubuntu, RHEL, Debian, and Alpine), a runtime profiler (RF Profiler) that emits a Runtime Bill of Materials (RBOM), and an optimizer (RF Optimizer) that strips unobserved components from arbitrary images.
The container base image determines the upper bound on every CVE, package, and post-compromise capability your application inherits. Standard public base images on Docker Hub typically ship with 50–60 known CVEs, 15–20 rated high or critical, plus shells, package managers, and utilities the application never executes.
Chainguard's 2024 State of Hardened Container Images report measured roughly 300 CVEs in the average Debian-based public image at pull time. Three root causes account for almost all of that surface.
The cost is not theoretical. CVE-2021-44228 (Log4Shell) carries a CVSSv3 base score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) and was added to the CISA Known Exploited Vulnerabilities catalog on December 10, 2021.
Any image bundling Log4j 2.0-beta9 through 2.14.1 inherited the exposure regardless of whether the container's primary application used it. MITRE ATT&CK for Containers technique T1611 (Escape to Host) assumes the attacker uses whatever post-exploitation tooling is already on disk; an image without a shell or package manager limits that toolkit by default.
NIST SP 800-190 section 4.1.1 codifies the inventory expectation, and section 4.3.2 codifies capability minimization. Both vendors reviewed here exist because the default base image violates both controls. Teams evaluating the broader category often start with hardened container images and survey minimal distroless images before short-listing vendors.
Minimus builds hardened container images directly from upstream source code, including only the runtime components the application requires. Each Minimus image is rebuilt continuously, signed, and shipped with a SLSA build attestation, a cryptographically signed SBOM, and published VEX data.
Minimus does not patch a stripped public image. It compiles components from upstream sources with controlled compilation flags, and every package can be traced back to its source revision.
That property is what makes a backport possible without waiting for Canonical, Red Hat, or Debian to ship a fix. The resulting image is not bound to any LTS distribution's "won't fix" classification.
Minimus publishes a contractual 48-hour remediation SLA aligned to CVSS severity and the CISA KEV catalog. The SLA appears in procurement contracts, not only in marketing collateral.
Compare that with a "continuous patching" claim that does not specify a contractual time bound or a remedy if the cadence slips during a long weekend.
Minimus images do not suppress CVEs to keep scanner output green. Every detected CVE is published in VEX with one of three dispositions: present-and-exploitable, present-and-not-exploitable, or fixed.
Security teams reviewing scanner output (Trivy, Grype, Snyk, and Prisma Cloud) can collapse hundreds of findings into the small subset that needs work this sprint, without losing the audit trail.
Minimus ships 1,000+ pre-built minimal images covering common runtimes (nginx, postgres, openjdk, node, python, and golang). When the catalog does not cover a specific runtime configuration, Image Creator builds custom minimal images from upstream sources to the same standard, on the same SLA.
The public catalog lives at images.minimus.io and platform documentation lives at docs.minimus.io.
RapidFort hardens container images two ways. A curated catalog of 25,000+ Near-Zero CVE images is built on standard LTS distributions (Ubuntu, RHEL, Debian, and Alpine) and continuously patched. A runtime profiler (RF Profiler) generates a Runtime Bill of Materials (RBOM) used by RF Optimizer to strip unused components from any image.
RapidFort publishes 25,000+ pre-built images on stock LTS distros, rebuilt on a 24-hour cadence. Positioning is "true open source, no vendor lock-in."
These images remain derived from upstream LTS distro packaging. CVE elimination depends on upstream patch cadence and RapidFort's curation cadence rather than a from-source rebuild controlled end-to-end by the vendor.
RF Profiler observes container behavior in production with under 1% reported overhead. It emits an RBOM identifying which packages, binaries, and libraries actually execute under real traffic.
The RBOM becomes the input artifact for RF Optimizer, which makes profiling completeness the upstream dependency for every downstream stripping decision.
RF Optimizer removes packages, binaries, and libraries the RBOM did not observe in execution. RapidFort claims up to 99.9% CVE reduction and 90% attack surface reduction on optimized images.
The mechanism is package stripping rather than recompilation. The resulting image still carries the upstream LTS distribution's binary lineage and patch cadence.
RF Analyzer reduces vulnerability noise across registries, CI, and clusters by approximately 25% per RapidFort's reporting. RF CART (continuous compliance) generates audit evidence aligned to CIS and STIG benchmarks for FedRAMP, CMMC, and SOC 2 programs.
The compliance evidence shape is a continuous report, not a per-image SBOM and VEX bundle.
Post-build optimization techniques like RapidFort's RBOM-driven RF Optimizer reduce attack surface effectively for steady-state runtime behavior. They introduce three structural limitations: incomplete code-path coverage, profile staleness, and dependence on upstream binary provenance.
Components stripped because they were not exercised in the profile window can break batch jobs, error-handling paths, infrequent features, debug workflows, and any code path activated only after a configuration change. The profile is a snapshot of what ran during observation, not a guarantee of what is needed in production.
The first time I watched this fail in a customer environment was a Java payments service whose monthly chargeback reconciliation job called a JDBC driver class never touched during the 10-day profile window. The optimized image shipped without the driver path.
The next month-end run failed at 02:14 UTC with a ClassNotFoundException. It took 90 minutes to diagnose because the scanner showed zero CVEs and the dashboard was green. That kind of failure is the worst kind: silent until the calendar trips it.
A new feature, a new library version, or a new traffic pattern requires re-profiling and re-optimizing. Without that discipline, the optimized image becomes incorrect or unsafe over time.
The remediation cycle is no longer "patch the CVE"; it is "re-profile, re-optimize, re-test, re-deploy" for every change touching dependency surface area. The teams that get this right run a parallel un-optimized image in a shadow environment for at least one full release cycle.
RBOM-driven stripping removes the unused. CVEs in packages the application actually executes remain present until upstream patches them or the vendor backports a fix.
Build-from-source images close this gap because the vendor controls the right to issue a backport on its own SLA. The 99.9% CVE reduction figure should be read as "99.9% of the CVE inventory present in the unoptimized image was not observed in execution," which is a different claim from "the residual CVEs are remediated."
A stripped Ubuntu image is still an Ubuntu image, governed by Canonical's packaging cadence, build infrastructure, and "won't-fix" classifications. SLSA Build L3 attestations on the optimized image attest to the optimization pipeline, not to the original component build provenance.
Chainguard's 2024 State of Hardened Container Images report measured one container debloating technology at approximately a 65% CVE reduction, against the 95–97% reduction reported by build-from-source vendors. That benchmark is published by a competitor, but it is the most concrete public number on the upper bound of stripping-based approaches.
Minimus and RapidFort produce different audit evidence, different scanner output, and different operational tradeoffs at scale. The choice between them depends on whether the buyer's primary constraint is the integrity of the build pipeline or the ease of migrating an existing fleet onto lower-CVE images without re-architecting workloads.
The audit-evidence shape is the difference procurement teams underestimate most often. A FedRAMP 3PAO reviewing per-image SBOM and VEX bundles asks different questions than one reviewing a continuous compliance dashboard.
Procurement teams should request sample evidence packages from both vendors and walk a 3PAO through them before signing. In two of the last three FedRAMP-aligned migrations I reviewed, the evidence-format question was the deciding factor procurement spotted only at the 3PAO walkthrough.
Choose Minimus when build provenance, contractual remediation SLAs, and verifiable SBOM and VEX evidence are the primary constraints, particularly in FedRAMP- and STIG-oriented environments with FIPS 140-3 requirements. Choose RapidFort when the primary goal is lowering CVE counts on an existing Ubuntu or RHEL fleet without changing the underlying distro or re-architecting workloads.
Choose Minimus if:
Choose RapidFort if:
Choose both, in different parts of the fleet, if:
The next paragraphs are anecdotal guidance from migrations I have reviewed, not vendor claims. Across regulated and commercial fleets, the split tends to fall along team lines, not technology lines. One platform team I worked with last year ran a 40-service migration over three quarters: roughly a dozen new microservices launched on build-from-source minimal bases, and the remainder of legacy Ubuntu 20.04 services moved through post-build optimization while their refactor backlog cleared.
The team that owned the new services pushed back on every conversation about stripping LTS images. The team that owned the legacy fleet pushed back on every conversation about re-baselining onto minimal distros. Pretending one vendor fits both is how procurement decisions get reopened a year later.
Organizations standardize on hardened container images because public base images carry inherited CVEs, weak provenance, and post-compromise tooling that complicates every downstream security control. NIST SP 800-190 sections 4.1.1 and 4.3.2 codify the inventory and capability-minimization expectations that hardened image programs satisfy by design.
Four cross-vendor adoption drivers explain why the category is growing across compliance regimes:
The vendor field is wider than two names. Iron Bank, Chiselled Ubuntu, Docker Hardened Images, Bitnami Secure Images, Echo, and Chainguard all ship in this category with different strategic emphases. Teams running cross-vendor evaluations should map the wider field before committing to a primary vendor.
Minimus and RapidFort solve the same business problem (too many CVEs in too many container images) through opposite technical approaches. The right vendor for a given organization depends on whether the constraint is verifiable build provenance and SLA-backed remediation (Minimus) or migrating an existing fleet to lower-CVE images on stock LTS distros without re-architecting (RapidFort).
Three takeaways for the procurement file:
Honest caveat: hardened or minimal container images do not replace runtime threat detection, network policy, EDR on the host node, or admission control. They make those layers more effective by reducing noise, not by replacing them.
Minimus and RapidFort are container image security vendors that reduce CVEs through opposite architectural approaches. Minimus builds minimal container images directly from upstream source code on a 48-hour critical-CVE rebuild SLA. RapidFort optimizes existing public LTS images by profiling runtime usage and stripping unused components.
RapidFort is a software supply chain security platform used to reduce container CVEs through two complementary mechanisms. Curated Near-Zero CVE Images provide 25,000+ pre-built LTS-based images on a 24-hour rebuild cadence. RF Profiler and RF Optimizer reduce attack surface on customer images by stripping components not observed in production runtime traffic.
RapidFort and Chainguard target the same outcome (lower-CVE container images) using different methods. RapidFort optimizes existing LTS-based images via runtime profiling and post-build stripping. Chainguard ships minimal images built from source on its own pipeline, with signed SBOMs and published VEX. Choose RapidFort to migrate an existing LTS fleet; choose Chainguard or a similar build-from-source vendor for new platforms requiring source-traceable provenance.
The active vendor field includes Minimus (build-from-source minimal images, 48-hour SLA), Chainguard (build-from-source minimal images on its own distro), Echo (build-from-source minimal images), Docker Hardened Images (Apache 2.0 hardened drop-ins from Docker), Bitnami Secure Images (Broadcom catalog), and Iron Bank (USAF accredited containers for DoD workloads).
RapidFort is positioned as a software supply chain security platform with DevSecOps pipeline integration. It connects to CI/CD systems, container registries, and Kubernetes admission controllers to feed its profiling, optimization, and curated image workflows. It is not a full DevSecOps platform replacing CI/CD, planning, or developer collaboration tools.