CVE remediation is the process of identifying, prioritizing, and resolving Common Vulnerabilities and Exposures across the software you run in production. The CVE program disclosed over 40,000 new vulnerabilities in 2024 per the CVE.org public dashboard, and most security teams cannot patch all of them on the day they appear. Volume is the hard part.
This guide covers what CVE remediation involves, how the lifecycle works, why containerized environments change the math, and which databases and tools security teams use to keep up.
CVE remediation is the end-to-end process of finding a known vulnerability in software you run, deciding whether and how urgently to fix it, applying a patch or workaround, and verifying the fix held. A CVE (Common Vulnerabilities and Exposures) is a unique identifier issued by MITRE for a publicly disclosed software flaw. CVE-2024-6387 (regreSSHion), for example, identifies a signal handler race condition in OpenSSH server that allowed unauthenticated remote code execution as root on glibc-based Linux systems.
Remediation is broader than patching. A patch is one option. The full set includes:
The wrong question is "have we patched everything?" The right one is "have we addressed every CVE that materially raises breach risk in our environment?" Those are different lists, and confusing them is how teams burn quarters on low-impact fixes while a KEV-listed CVE on a public-facing service stays open.
The lifecycle has five stages that run continuously, not sequentially. Most mature programs treat them as parallel pipelines feeding a central ticket queue.
Discovery starts with knowing what you run. Authenticated scanners (Tenable Nessus, Rapid7 InsightVM, Qualys VMDR), agent-based tools (CrowdStrike Spotlight), and SBOM-based scanners (Trivy, Grype, Snyk) generate findings against an asset inventory. Remediation accuracy ceilings out at inventory accuracy: missed assets produce false negatives that auditors will eventually find.
CVSS base score alone is a poor prioritization signal. Roughly 16,000 CVEs disclosed in 2024 had a CVSSv3 base score of 7.0 or higher per NVD data, and no team patches 16,000 high or critical CVEs in a year. The functional approach combines:
A CVE with a CVSS of 6.5, an EPSS of 0.92, and KEV membership outranks a CVE with CVSS 9.8, EPSS of 0.001, and no KEV listing every time.
Execution depends on the platform: Windows via WSUS or SCCM, Linux via package manager, container images via rebuild and redeploy, network appliances via vendor firmware update. Fragmentation is why most enterprises maintain three to five separate remediation pipelines and a single SLA tracker on top.
Verification means rescanning the asset to confirm the CVE no longer appears. Trust the rescan, not the patch deployment status. Patches fail to apply more often than vendor reports admit.
PCI-DSS v4.0 requirement 6.3.3, SOC 2 CC7.1, and ISO 27001 control A.12.6.1 all require evidence that vulnerabilities were addressed within defined timeframes. Auditors want timestamps. A ticket history with disclosure date, prioritization decision, remediation date, and verification scan is the artifact they ask for.
CVE remediation in containers replaces in-place patching with rebuild and redeploy. Instead of running apt upgrade on a live host, you rebuild the image with patched packages, push it to your registry, and roll out a new deployment. The unit of remediation is the image digest, not the running process.
This is structurally faster than traditional server patching when the maintainer ships updates promptly. CVE-2025-24813, an Apache Tomcat partial PUT request flaw disclosed in March 2025, was patched in upstream Tomcat 9.0.99, 10.1.35, and 11.0.3 on the day of disclosure. Teams running Tomcat in containers from a maintainer who tracks upstream could pull the patched base image and redeploy within hours. Teams on long-lived VMs were on a slower curve dictated by their change management process.
The catch is that container security only inherits the patch cadence of the upstream image. Pull tomcat:latest once and forget about it, and you are exposed to every CVE disclosed against that version until you remember to repull. Continuous rebuilds, where the registry rebuilds the image each time an upstream package is patched, change the equation: the image is current because someone else makes it current.
For a deeper look at how this works in practice, including the mechanics of pulling and verifying rebuilt images, see fast Go CVE remediation with hardened container images. The supporting piece on how teams track and prioritize CVEs with vulnerability intelligence covers the prioritization side of containerized remediation specifically.
The strategy you pick depends on whether a patch exists, how exposed the affected component is, and how much downtime your change window allows. Most teams use a mix of the four below.
The default. The vendor publishes a fixed version, you upgrade. CVE-2020-6287, the SAP NetWeaver RECON vulnerability with a CVSSv3 of 10.0, had vendor remediation steps published in SAP Security Note 2934135 the same day as the CVE disclosure in July 2020. CVE-2023-38408 (OpenSSH ssh-agent forwarding RCE) was patched in OpenSSH 9.3p2. Vendor patches are the cleanest path when downtime is tolerable.
When a patch is not yet available, the vendor often publishes a configuration change that closes the attack vector. CVE-2023-44487 (HTTP/2 Rapid Reset, exploited at scale against major cloud providers in October 2023) had a workaround documented by NGINX, HAProxy, and Cloudflare days before all upstream patches landed: rate-limit HTTP/2 RST_STREAM frames per connection. Workarounds are the right move when patching requires a maintenance window you cannot get this week.
Sometimes the patch is not feasible. Embedded devices, end-of-life systems, and mainframe workloads frequently fall here. CVE-2016-2183 (SWEET32, the 3DES birthday attack) is still flagged on legacy Java applications and network appliances in 2026. Where the TLS library cannot be upgraded, the compensating control is to disable 3DES cipher suites at the load balancer, the WAF, or both. Document the control as the remediation in the audit trail.
If the affected component is not required, remove it. CVE-2016-4655, the kernel information leak chained in the Pegasus iOS exploit, was remediated by Apple via the iOS 9.3.5 update. For organizations whose only exposure was a managed device fleet, the remediation was a forced device update through MDM. Removal is also the cleanest answer to vulnerable open source libraries you depended on but never actually called: delete the dependency, the CVE goes away.
The CVE remediation database landscape is fragmented across authoritative sources, scanners, and aggregators. The ones that actually matter:
Scanner choice depends on the surface. Tenable, Qualys, and Rapid7 dominate enterprise host scanning. Trivy and Grype lead in containers. Snyk and Mend cover application dependencies. For embedded devices, CVE monitoring and remediation is typically handled through SBOM-driven tools like Anchore Enterprise paired with vendor-specific firmware update mechanisms, since standard host scanners do not work on devices without an agent surface.
The 40,000+ CVE disclosure rate is only the surface problem. Three structural shifts have made remediation harder than it was five years ago.
Asset volatility. Containers and serverless functions live for minutes or hours. A scanner finding a CVE on a pod that no longer exists is technically correct and operationally useless. Remediation has to happen at the image and template layer, which inverts the workflow that traditional vulnerability management tools were built around.
Multi-cloud sprawl. Enterprises often run workloads across AWS, Azure, GCP, on-prem VMware, and Kubernetes. Each surface has its own scanner, patching mechanism, and SLA tracking. CVE monitoring and remediation across embedded devices adds a fourth or fifth surface where standard tooling does not apply.
Patch fatigue. Microsoft's Patch Tuesday in February 2024 included 73 CVEs across 60+ products. Apache Log4j (CVE-2021-44228) was patched in December 2021 and is still found unpatched in production in 2026. The bottleneck is not awareness. It is the operational overhead of testing, scheduling, and deploying patches across thousands of systems while keeping production stable.
The teams that handle this well share a common pattern: they shift remediation left to the build stage wherever they can, so the running fleet inherits a smaller starting CVE count. That is the answer to "how do we handle CVE remediation in containers?" — you make the image arrive with fewer CVEs in it, and the in-life patching workload shrinks accordingly.
CVE remediation works when the volume gets cut down before triage starts. Programs that try to patch every CVE on every system fail the same way: backlogs grow, exceptions pile up, and KEV-listed vulnerabilities sit open on internet-facing services because the team is busy patching low-EPSS findings on internal lab boxes.
Cutting starting volume at the build layer is the structural fix. Minimus builds container images directly from upstream sources with only the packages required to run the application, so a Minimus image typically ships with 95%+ fewer CVEs than the equivalent standard public image, with supporting benchmark data published and a contractual 48-hour remediation SLA on newly disclosed critical and high severity CVEs. Browse the catalog at images.minimus.io, read the docs at docs.minimus.io, or get started to compare your current CVE footprint against a Minimus equivalent.
CVE remediation in containers means rebuilding the affected image from a patched base and redeploying, not patching the running container. The unit of remediation is the image digest. Teams typically pull a patched upstream image (or rebuild from upstream source if they maintain their own pipeline), push the new image to their registry, and roll out a new deployment via Kubernetes, ECS, or whichever orchestrator they use. The two factors that determine how fast this happens are the patch cadence of the base image maintainer and the speed of your CI/CD pipeline. Continuous rebuilds at the base image layer and a tested rollout pipeline together are what make container CVE remediation faster than traditional VM patching.
Vulnerability management is the broader program: discovery, asset inventory, scanning, prioritization, remediation, verification, and reporting. CVE remediation is the specific subset focused on resolving disclosed CVEs once they are identified. A vulnerability management program also handles findings without CVE identifiers, such as misconfigurations, weak credentials, and exposed secrets, which CVE remediation alone does not cover.
NVD (nvd.nist.gov) is the authoritative source for CVE metadata, but cross-reference with vendor advisories and the GitHub Advisory Database. NVD has had enrichment backlog issues since early 2024, so vendor advisories from Microsoft MSRC, Red Hat RHSA, Ubuntu USN, and Debian DSA often have fix information available before NVD updates. For prioritization, layer CISA KEV (active exploitation) and FIRST.org's EPSS (exploitation probability) on top of NVD's CVSS data.
CISA's Binding Operational Directive 22-01 mandates 14 days for federal agencies to remediate KEV-listed CVEs after they are added to the catalog. Most enterprise SLAs use 14 to 30 days for critical, 30 to 90 for high, and 90+ for medium and low. The SLA matters less than whether you actually meet it: a 30-day critical SLA you hit consistently is more useful than a 7-day SLA you miss every quarter.
CVE monitoring and remediation for embedded devices is harder than for servers because most embedded firmware does not support agent-based scanning, and patches require vendor firmware updates that often need physical access or a long support contract. The practical approach is SBOM-based: get an SBOM from the device manufacturer, monitor it against the NVD and vendor advisory feeds, and apply firmware updates through the vendor's official channel when available. Where firmware updates are not available, network segmentation and protocol-level filtering become the de facto remediation.
.svg)
.svg)
.svg)
.svg)
