How to cut container CVE remediation from months to 48 hours

A financial services team facing 5,286 container vulnerabilities got an estimate of three months and five to six engineers to clear them. They finished in 48 hours, with three vulnerabilities left that had no fix available yet. They got there in three steps: runtime profiling to close findings that couldn't affect them, drop-in curated images to replace inherited base layers, and removal of packages the application never loaded. This article walks through that container CVE remediation process, how CISA's BOD 26-04 changes which findings you fix first, and how to run the process on every build so the backlog doesn't return.

The examples come from RapidFort's work with a couple hundred customers preparing for FedRAMP, CMMC 2.0, and CRA compliance, as presented in our webinar, Best Practices for Software Supply Chain Security webinar.

Why container vulnerability backlogs keep growing

Most of the code in your containers came from someone else. Base OS layers, OS packages, language runtimes such as Python, Node, and Java, and their transitive dependencies sit underneath your application binaries. In a typical image, first-party code is 10% or less of what you ship, and open source components appear in 96% of commercial codebases.

Every inherited package multiplies across your estate. A base image with 100 CVEs, used by 100 services, produces 10,000 scanner findings from a single root cause. Scanners report each one because they check whether a vulnerable package exists in the image. They don't check whether that package loads or executes.

Patching those findings by hand has no finish line. In RapidFort customer environments, a set of eight freshly patched containers now accumulates a couple hundred new findings within a week. For engineering leaders, that makes vulnerability work a standing drain on roadmap capacity. The team in this article estimated a full quarter for five or six engineers, with a real risk that package upgrades would break the application.

Moving to a cleaner base image from a different Linux distribution creates its own problem. Your developers inherit a new package manager and new Dockerfile conventions, and a security fix turns into a migration project that stalls on adoption.

How BOD 26-04 changes which CVEs you fix first

Severity-first triage works through criticals within seven days and highs within 30, in CVSS order. CISA's Binding Operational Directive 26-04 sets remediation deadlines by four factors instead:

• Exposure: Is the affected asset reachable from the internet?
• KEV status: Is the CVE listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, meaning attackers have exploited it in real incidents?
• Automatability: Can an attacker exploit it without manual steps?
• Technical impact: Would a successful exploit give an attacker control of the application or its data?

Those answers set the clock. An exposed KEV gets a 24-hour window. An exposed, automatable CVE with high technical impact gets three days, even when its CVSS rating is low. A critical that is unexposed, outside the KEV catalog, but is automatable gets 60 days. BOD 26-04 is expected to become a FedRAMP 20x requirement in December 2026.

For a CISO, this means a backlog sorted by CVSS no longer reflects real exposure, and a count of open criticals tells your board and auditors little. Each finding needs runtime evidence: whether the package loads, whether the vulnerable code runs in your configuration, and whether the workload is exposed. RapidFort's BOD 26-04 dashboard tracks those clocks per CVE; read more in Turning CISA's BOD 26-04 into live clocks for critical infrastructure.

That evidence shrinks most backlogs. Sysdig reported that 85% of critical and high vulnerabilities with an available fix sat in packages that weren't loaded at runtime, and JFrog found that 78% of CVEs across 200 popular Docker Hub images weren't exploitable in practice.

Not-affected decisions also have to hold up in an audit. FedRAMP and CMMC reviewers expect a plan of action and milestones (POA&M) with a justification for every exception. RapidFort records each not-affected determination in VEX format with a written summary and links to the NVD entry. For example, a glibc CVE that affects only IBM Power10 processors is marked not affected on an AMD64 image, with the architecture mismatch documented. A dedicated team of 50 RapidFort engineers reviews these determinations alongside multi-scanner comparisons.

How one team cleared 5,286 vulnerabilities in 48 hours

The customer needed zero critical and high vulnerabilities before deploying into a large financial institution. They worked through three steps, each one shrinking what the next had to handle.

Step 1: Profile the application at runtime

The team deployed the RapidFort Profiler in their QA environment to generate a runtime bill of materials (RBOM®), a record of the packages and files that actually load and execute, alongside the standard SBOM. Profiling showed that 1,700 of the 5,286 findings couldn't affect their deployment. Those tickets closed with VEX justifications attached, with no engineering work required.

Step 2: Replace base images with drop-in curated images

That left 3,586 vulnerabilities. Instead of upgrading packages image by image, the team replaced each base image with a RapidFort Curated Images equivalent on the same distribution and version, including Ubuntu 20.04 and Alpine 3.20. The operating system, package manager, and version numbers stayed the same, so developers kept their Dockerfiles. The rebuild took about 90 minutes and brought the count to roughly 500.

The same pattern holds in smaller estates. On one eight-container deployment, replacing a Docker Hub MongoDB image cut its findings from 155 to three, and rebuilding a Node application on a curated Ubuntu Jammy base cut 521 findings to nine. Across all eight containers, the total fell from 1,661 to 24 with no library changes.

Step 3: Remove what the application never loads

Most of the remaining 500 findings came from third-party packages installed on top of the base images. Profiling surfaced a Bluetooth driver package carrying 125 vulnerabilities in an application that never used Bluetooth. The RapidFort Optimizer removed the packages the RBOM® showed as unused, which shrank the image from 1.8 GB to 262 MB and left three vulnerabilities with no fix available yet.

Size reductions of 60% to 80% are typical for Python, Node, and Java images. Go and Rust images, and images already built on distroless or scratch bases, see about 30%. Removing unused shells, package managers, and build tools also takes away the utilities an attacker would use to move laterally after gaining access to a container.

How to run container CVE remediation on every build

A one-time cleanup starts decaying as soon as new CVEs are published. The team above keeps its count near zero by running all three steps in its CI/CD pipeline:

1. Profile in QA. Install the RapidFort Helm chart, which deploys a DaemonSet to your Kubernetes QA cluster. Run at least one full QA test cycle, then leave the profiler running so it keeps learning.

   helm install rfruntime oci://quay.io/rapidfort/runtime \
     --namespace rapidfort \
     --set profile.enabled=true \
     --wait

2. Mirror curated images into your registry. Pull same-distribution curated images into your private registry so builds pick them up without developer changes. The images are patched daily, signed with Sigstore Cosign, and ship with SLSA attestations. You can verify the signature and re-sign with your own key.
3. Apply the optimization profile at build time. Before each build, take a snapshot of the current profile so the build strips components the application hasn't used.
4. Record not-affected decisions in VEX. Ship the VEX file with the image so auditors and downstream scanners see the same justifications your team does.

The profile combines behavior from every node in the cluster where the application runs. When a new code path appears, the profile updates and the next build keeps that package. For serverless workloads where you can't install a DaemonSet, the profiler runs inside the container in your staging environment. Profiling runs only in QA or staging and never ships to production.

Profiling depends on test coverage. A code path your tests never exercise, such as a quarterly batch job or a rarely triggered error handler, can end up on the removal list unless the profiler detects it. RapidFort supplements observed execution with memory-allocation and dependency analysis to catch infrequent paths, custom hardening profile files, and a thorough QA cycle remains your best protection. Review the removal list for rarely run functions before your first optimized release.

Four numbers to pull from your backlog this week

You can size the opportunity with data you already have:

• The share of your last scan's findings that came from first-party code versus inherited base, OS, and framework layers.
• How your backlog order changes when you sort by exposure, KEV status, and reachability instead of CVSS.
• How many findings in last quarter's reports were CVEs your team had already closed once.
• How many distinct base images your teams pull, and who approved each one.

If most findings are inherited, recurring, and unreachable, the three-step process above will return more engineering time than any amount of manual patching.

George Manuelian, RapidFort's Chief Strategy Officer, walks through each step with live dashboard examples and audience Q&A on RBOM accuracy, serverless profiling, and BOD 26-04 in the full session. Watch Best Practices for Software Supply Chain Security on demand