Vulnerability Management Lifecycle: From CVE Discovery to Remediation

A single unpatched vulnerability in a container image can compromise your entire production environment. In 2025 alone, over 40,000 new CVEs were published — roughly 110 per day. The SolarWinds, Log4j, and MOVEit incidents each cost affected organizations hundreds of millions of dollars, and every one of those attacks started with an unpatched vulnerability that was already known to security teams. The difference between a minor incident and a catastrophic breach is not whether you scan for vulnerabilities — it is whether you have a systematic lifecycle to discover, prioritize, and remediate them before attackers strike.

Vulnerability management for containerized applications is fundamentally different from traditional patching. Containers include application code, system libraries, and a base operating system — all bundled into an immutable image. When a new CVE is published, you must rebuild, rescan, and redeploy every affected container image. Without a structured lifecycle, teams drown in alert fatigue, miss critical CVEs buried beneath thousands of irrelevant findings, and fail to meet compliance deadlines. This article walks through the complete vulnerability management lifecycle — from CVE discovery through verification — with practical commands, CI/CD integration patterns, and real-world case studies.

Why a Structured Vulnerability Management Lifecycle Matters

Organizations without a formal vulnerability management process share a common pattern: they scan reactively, treat every alert as an emergency, and still miss critical vulnerabilities. The Ponemon Institute's 2025 Cost of a Data Breach report found that organizations with mature vulnerability management programs detected breaches 65 days faster and saved an average of $1.4 million per incident compared to those without structured programs. In container environments, the stakes are higher because a vulnerable base image propagates to every container built from it — one badFROM instruction can affect hundreds of microservices across multiple environments.

The vulnerability management lifecycle provides a repeatable framework that prevents these outcomes. Rather than reacting to each new CVE as a crisis, teams follow defined stages that separate discovery from prioritization, remediation from verification. This systematic approach is required by major compliance frameworks: PCI DSS Requirement 6 demands a formal vulnerability management program, NIST SP 800-190 mandates continuous monitoring and remediation, and SOC 2 CC7.1 requires detection and response to security incidents — including vulnerability exploitation.

The 6 Stages of the Vulnerability Management Lifecycle

While different frameworks define slightly different stages, the industry-standard lifecycle maps to six sequential phases:

1. Asset Discovery and Inventory— Identify every container image, host, and dependency in your environment
2. Vulnerability Scanning and Assessment— Scan all assets against known CVE databases
3. Risk Prioritization and Triage— Separate critical threats from noise using severity, exploitability, and business context
4. Remediation Planning— Determine the fix strategy: patch, mitigate, or accept
5. Remediation Execution— Apply fixes through rebuilt images, configuration changes, or compensating controls
6. Verification and Continuous Monitoring— Confirm the fix works and monitor for regression or new CVEs

This lifecycle aligns with theOWASP DevSecOps Guideline, which emphasizes integrating security testing into every stage of the continuous delivery pipeline rather than treating it as a separate audit gate.

Each stage feeds into the next, and the lifecycle repeats continuously — not as a quarterly event but as an integrated part of your development and operations pipeline.

Stage 1: Asset Discovery and Inventory — Know What You Run

You cannot secure what you cannot see. The first stage of the vulnerability management lifecycle is building a complete inventory of every container image, base image, registry repository, and running workload in your environment. In Kubernetes, this means discovering all pods across all namespaces — including those inkube-system and third-party operator namespaces that teams often overlook.

Use the following command to get a complete picture of all container images running in your cluster:

kubectl get pods --all-namespaces -o jsonpath="{range .items[*]}{.spec.containers[*].image}{'\n'}{end}" | sort -u

For Docker environments, list all locally stored images with their digests — not just tags, because tags can be overwritten:

docker images --digests --format "table {{.Repository}}:{{.Tag}}\t{{.Digest}}"

Modern container registries also maintain image inventories. For Harbor, the registry API provides a complete list:

curl -s "https://harbor.example.com/api/v2.0/projects/myproject/repositories" | jq '.[].name'

Automate asset discovery by integrating with your CI/CD system — every time a build produces a new image, register it in your vulnerability management database. Without this step, you will inevitably miss images that were built months ago and are still running in production with known critical vulnerabilities.

Stage 2: Vulnerability Scanning and Assessment — Finding the Gaps

Once you have a complete asset inventory, the next stage is scanning every image against known CVE databases. The Open Vulnerability Database (NVD) maintained byNISTis the authoritative source, but tools like Trivy, Grype, and Docker Scout provide automated scanning by cross-referencing the packages in your image against the NVD, GitHub Security Advisories, and other feeds.

Run a comprehensive scan on a single container image with Trivy:

trivy image --severity CRITICAL,HIGH --format table --ignore-unfixed nginx:1.25

The--ignore-unfixed flag is critical — it filters out vulnerabilities that have no available fix, allowing you to focus on actionable findings. To generate an SBOM (Software Bill of Materials) first and then scan it, use the two-step approach that aligns with CIS Docker Benchmarksupply chain security best practices:

docker scout sbom nginx:1.25 > nginx-sbom.json
docker scout quickview --sbom nginx-sbom.json

For CI/CD pipelines, scanning must happen at multiple stages: when a developer commits code (SAST), when an image is built (container scan), when it is pushed to the registry (registry scan), and before deployment to production (admission control). Each stage catches different classes of vulnerabilities — code-level flaws, dependency CVEs, and configuration weaknesses.

Stage 3: Risk Prioritization and Triage — Fighting Alert Fatigue

The average container image contains over 100 packages, and a typical Trivy scan on a standard Node.js base image returns 200-400 findings — most of which are Low or Medium severity. Without prioritization, teams spend 80% of their time investigating false positives and irrelevant findings. The third stage of the lifecycle separates signal from noise.

Use theCVSS scoring systemcombined with exploit intelligence to prioritize:

• Critical (CVSS 9.0-10.0)— Remediate within 24 hours. These vulnerabilities typically allow remote code execution with no authentication required.
• High (CVSS 7.0-8.9)— Remediate within 7 days. These often require some preconditions but have significant impact.
• Medium (CVSS 4.0-6.9)— Include in next sprint or standard patch cycle (14-30 days).
• Low (CVSS 0.1-3.9)— Accept or defer. Monitor for changes in exploit status.

The CISA Known Exploited Vulnerabilities (KEV) catalog adds another critical dimension. Any CVE on the KEV list must be treated as an immediate priority regardless of its CVSS score because attackers are actively using it. Check the KEV catalog programmatically:

curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" | jq '.vulnerabilities[] | select(.cveID=="CVE-2024-3094")'

For container-specific prioritization, also consider: Does the vulnerable package run in production or only in a development stage? Is the component network-facing or internal? Is the vulnerability exploitable with the default configuration? A high-severity CVE in a development-only npm package that never touches production data is far less urgent than a medium-severity CVE in a production-facing OpenSSL library.

Stage 4: Remediation Planning — Patch, Mitigate, or Accept

After prioritization, the fourth stage decides what to do with each vulnerability. Three options exist, and each requires different effort and risk:

1. Patch (Recommended)— Rebuild the container image with an updated base image or upgraded dependency. This is the only permanent fix. For example, ifalpine:3.18 has a critical libc vulnerability, rebuild with alpine:3.19:

   FROM alpine:3.19
   RUN apk update && apk upgrade --no-cache
   # ... rest of application

2. Mitigate— Apply a compensating control that blocks the attack path without patching the underlying vulnerability. Options include network segmentation (block traffic to the vulnerable service), WAF rules (filter exploit payloads), or seccomp profiles (block system calls used by the exploit). Mitigation is a temporary measure while a permanent patch is developed or tested.

3. Accept— Document the vulnerability, the business rationale for not remediating, and any compensating controls that reduce the risk. Acceptance must have a formal review and an expiration date. Common reasons: the vulnerability is behind a VPN, affects a non-production system, or has no known exploit path in your architecture.

Document every remediation decision in a vulnerability tracking system. This documentation is essential for compliance audits — PCI DSS assessors will ask for evidence that vulnerabilities were reviewed and decisions were recorded.

Stage 5: Remediation Execution — Patching at Container Speed

Executing remediation in container environments requires rebuilding and redeploying images — not just updating packages on running systems. The immutable infrastructure model means you cannot SSH into a container andapt-get upgrade. Instead, you rebuild the image from scratch with the fix and replace the running container:

# Build updated image
FROM alpine:3.19
RUN apk update && apk upgrade
COPY . /app
RUN pip install --no-cache-dir -r requirements.txt

# Build, tag, push
docker build -t myapp:v2.1 .
docker tag myapp:v2.1 registry.example.com/myapp:v2.1
docker push registry.example.com/myapp:v2.1

# Roll out in Kubernetes
kubectl set image deployment/myapp myapp=registry.example.com/myapp:v2.1
kubectl rollout status deployment/myapp

Automate this process in CI/CD. When a critical CVE is detected in a production image, the pipeline should trigger an automated rebuild of the affected image with the minimal base image update, run the full test suite, and deploy to a staging environment for validation before production rollout. Tools like Renovate or Dependabot can automatically create pull requests when base images or dependencies have known vulnerabilities with available fixes.

For vulnerabilities without available fixes, coordinate with the upstream maintainer or implement the compensating control. The Log4j 2 vulnerability (CVE-2021-44228) is a textbook example — the initial patch was incomplete, and organizations had to apply multiple rounds of mitigations before the permanent fix was available. A phased approach with documented mitigations is acceptable for these situations.

Stage 6: Verification and Continuous Monitoring — Closing the Loop

The final stage of the lifecycle verifies that remediation was effective and establishes continuous monitoring to detect new vulnerabilities as they emerge. Rescan the rebuilt image to confirm the CVE no longer appears:

trivy image --severity CRITICAL,HIGH myapp:v2.1

If the CVE still appears despite upgrading the base image, the vulnerability may be in a transitive dependency that your upgrade did not address. In that case, escalate to a deeper investigation — check if the vulnerable package is actually loaded at runtime or if it is a dead code path.

Continuous monitoring means rescanning all production images at least every 24 hours. New CVEs are published faster than most teams can respond, so automated scanning must run on a schedule, not just on builds. Use a cron job with Trivy or your vulnerability scanner of choice:

0 6 * * * trivy image --severity CRITICAL,HIGH --exit-code 1 registry.example.com/myapp:v2.1 || send_alert.sh "Critical CVE detected in myapp"

Integrate with an alerting system (PagerDuty, Slack, or email) so that critical CVEs trigger immediate notifications to the security team. The lifecycle does not end — it loops back to Stage 1 as new images are built and new CVEs are published.

Real-World Consequences: The Cost of an Unpatched Vulnerability

The 2024 MOVEit Transfer breach by the Clop ransomware group exploited a single SQL injection vulnerability (CVE-2023-34362) that had been publicly known for only three days before exploitation began. The vulnerability affected Progress Software's MOVEit managed file transfer product, used by thousands of organizations worldwide. Despite a patch being released on May 31, 2023, many organizations failed to apply it within the window before Clop began mass exploitation on June 1.

The result: over 2,600 organizations were compromised, affecting an estimated 77 million individuals. The total economic damage exceeded $10 billion, including ransom payments, incident response costs, litigation settlements, and regulatory fines. The U.S. Securities and Exchange Commission (SEC) charged several companies for failing to disclose the breach in a timely manner, citing inadequate vulnerability management processes.

This case illustrates a critical failure in the vulnerability management lifecycle: the gap betweenknowingabout a vulnerability andactingon that knowledge. A structured lifecycle with automated scanning, clear SLAs, and enforced remediation timelines would have given affected organizations a fighting chance.

Compliance Mapping: Vulnerability Management in PCI DSS, NIST, and SOC 2

Major compliance frameworks all require formal vulnerability management programs. Below is a mapping of the lifecycle stages to specific control requirements as documented in theCIS Benchmarks for DevSecOps:

Lifecycle Stage	PCI DSS v4.0	NIST SP 800-190	SOC 2
Asset Discovery	Req 2.4 (inventory)	Section 3.1	CC3.1, A1.2
Vulnerability Scanning	Req 6.3 (quarterly + after changes)	Section 3.2-3.4	CC7.1
Risk Prioritization	Req 6.3.3 (risk ranking)	Section 3.5	CC5.2
Remediation	Req 6.3.4 (patch high/critical within 30 days)	Section 3.6	CC7.3
Verification	Req 11.3 (penetration testing)	Section 3.7	CC7.2

PCI DSS Requirement 6.3.4 specifically requires that critical and high-severity vulnerabilities are patched within 30 days. In container environments, this timeline is achievable only with automated scanning and CI/CD integration — manual patching cannot keep pace with the frequency of container updates and new CVE disclosures.

Related ShieldOps Reads

• Container Vulnerability Triage: Separating Real Threats From Noise— A deep dive into the prioritization stage
• CI/CD Pipeline Security: 15 Best Practices for Secure Deployments— How to embed vulnerability scanning in your pipeline
• ShieldOps Security Features— Overview of automated container security scanning
• Infrastructure as Code Security: Scanning Terraform and CloudFormation— Extending the lifecycle to IaC
• Container Security Architecture: The 4 Pillars of Defense— Understanding how vulnerability management fits into broader security
• Security Chaos Engineering: Breaking Containers to Make Them Stronger— Testing your vulnerability response through controlled experiments
• ShieldOps Compliance Documentation

Complete 6-Stage Vulnerability Management Checklist

Use this checklist to assess your organization's vulnerability management maturity. Each item maps to one stage of the lifecycle:

Stage 1: Asset Discovery

• ⬜ Complete inventory of all container images in production
• ⬜ Registry sync — every pushed image registered in vulnerability database
• ⬜ Kubernetes discovery — all pods across all namespaces cataloged
• ⬜ Dependency tracking — lock files and SBOMs stored per image version

Stage 2: Vulnerability Scanning

• ⬜ Automated scan on every image build (CI/CD gate)
• ⬜ Registry scan — continuous monitoring of stored images
• ⬜ Runtime scan — running containers rescanned every 24 hours
• ⬜ SBOM generation attached to every release artifact

Stage 3: Risk Prioritization

• ⬜ CVSS-based severity classification applied to all findings
• ⬜ CISA KEV catalog checked — KEV entries get immediate priority
• ⬜ Exploitability score considered in prioritization decisions
• ⬜ False positives documented and excluded from active queue

Stage 4: Remediation Planning

• ⬜ Critical CVEs: SLA of 24 hours for plan, 7 days for fix
• ⬜ High CVEs: SLA of 7 days for plan, 30 days for fix
• ⬜ Risk acceptance documented with business justification and expiry
• ⬜ Mitigation plan drafted for vulnerabilities without available fixes

Stage 5: Remediation Execution

• ⬜ Base images updated to latest patched version
• ⬜ Dependencies upgraded via Renovate/Dependabot PRs
• ⬜ Rebuilt images scanned before deployment
• ⬜ Canary deployment before full production rollout

Stage 6: Verification

• ⬜ Post-remediation scan confirms CVE resolved
• ⬜ Runtime monitoring active for new CVEs affecting same package
• ⬜ Audit trail of all remediation actions documented
• ⬜ Compliance report generated for assessor review

Frequently Asked Questions

What is the vulnerability management lifecycle?

The vulnerability management lifecycle is a structured six-stage process that organizations follow to identify, assess, prioritize, remediate, and verify security vulnerabilities in their systems. It typically includes asset discovery, vulnerability scanning, risk prioritization, remediation planning, remediation execution, and continuous verification. In containerized environments, this lifecycle must operate continuously because new CVEs are published daily and new container images are built hourly.

How often should I scan containers for vulnerabilities?

Container images should be scanned at every stage of the CI/CD pipeline: when a developer commits code, when an image is built, when it is pushed to a registry, before deployment to staging, and before production rollout. Additionally, running containers should be rescanned at least every 24 hours because new CVEs are published constantly — in 2025, over 40,000 new CVEs were registered, approximately 110 per day.

What is the difference between CVSS base score and exploitability score?

The CVSS base score (0-10) represents the intrinsic severity of a vulnerability based on its characteristics: attack vector, complexity, privileges required, user interaction, and impact on confidentiality, integrity, and availability. The exploitability score measures how easy it is to exploit the vulnerability — lower exploitability scores mean more conditions are required for a successful attack. A CVE with a high base score but very low exploitability (e.g., requiring physical access) may be lower priority than a medium-severity CVE that is actively exploited in the wild.

Should I patch every CVE immediately after discovery?

No — patching every CVE immediately is neither practical nor advisable. Many vulnerabilities have no active exploits, affect only non-production configurations, or require local access that attackers cannot obtain. Instead, use a risk-based approach: prioritize CVEs that are Critical or High severity, have known exploits (check the CISA KEV catalog), affect internet-facing components, and have a CVSS exploitability score above 2.5. For Medium and Low severity CVEs, follow your standard patch cycle (monthly or quarterly) unless evidence of active exploitation appears.

What is the CISA KEV catalog and how does it impact prioritization?

The CISA Known Exploited Vulnerabilities (KEV) catalog is a list of vulnerabilities that are known to be actively exploited in the wild. CISA requires federal agencies (and strongly recommends all organizations) to remediate KEV-listed CVEs within specific timeframes — typically 7 to 30 days depending on severity. Any CVE appearing in the KEV catalog should be treated as the highest priority, regardless of its CVSS score, because active exploitation means attackers have already weaponized it.

How does ShieldOps help with vulnerability management?

ShieldOps automates the vulnerability management lifecycle for containerized applications. It scans Dockerfiles, container images, and Kubernetes manifests against known CVE databases, provides risk-prioritized remediation recommendations with specific fix versions, integrates with your CI/CD pipeline through automated gate checks, and generates compliance-ready reports mapping findings to PCI DSS, NIST SP 800-190, and SOC 2 controls.

Can vulnerability management be fully automated?

While many stages of the vulnerability management lifecycle can be automated — including asset discovery, vulnerability scanning, prioritization based on severity and exploitability, and even automated patching for non-critical systems — human judgment is still essential for nuanced decisions. For example, deciding whether to accept the risk of a critical CVE that has no available fix, or determining whether a vulnerability in a development-only dependency is worth patching in production, requires understanding the specific business context that automation cannot fully replicate.

Conclusion: Building a Vulnerability Management Program That Scales

The vulnerability management lifecycle is not a one-time project or a quarterly checkbox — it is a continuous process that must be embedded into your development and operations workflows. The six stages of asset discovery, vulnerability scanning, risk prioritization, remediation planning, remediation execution, and verification form a closed loop that, when automated and enforced, prevents the most common path to breach: a known, unpatched CVE.

Start by assessing where your organization stands today. Do you have a complete inventory of every container image? Are you scanning at every CI/CD gate? Do you prioritize based on exploitability and business context, not just CVSS score? The checklist above provides a practical starting point for measuring your maturity across all six stages.

ShieldOps helps teams automate the vulnerability management lifecycle from end to end. From automated Dockerfile and container image scanning to risk-prioritized remediation recommendations and compliance-ready reports, ShieldOps transforms the firefighting cycle into a measurable, auditable security program.Start your free trial today.