A scanner reports 800 CVEs. Your security team has capacity to remediate 20 per week. At that rate, you’re 40 weeks behind—a full year of work, with new CVEs accumulating every day. The backlog grows. Engineers lose confidence in the process. Remediation becomes reactive instead of strategic.
This is the CVE noise problem, and it’s primarily a prioritization failure, not a resource failure. Most of those 800 CVEs are not equally urgent. Some are critical and reachable. Many are in packages that are present in the container image but never execute at runtime. Static scanners treat them identically.
Why Static Prioritization Doesn’t Work at Scale?
CVSS scores rank severity by potential impact under optimal attack conditions. They don’t account for whether the vulnerable code path is reachable in your specific environment, whether the package is loaded at runtime, or whether an attacker attempting to exploit the vulnerability would need to bypass multiple other controls first.
The result is a priority list that looks authoritative but is systematically misleading. A CVSS 9.8 CVE in a package that is present in the container image but never loaded at runtime is ranked above a CVSS 7.0 CVE in a library that processes every user request. From an actual risk perspective, the ordering is backwards.
Engineering teams that work through vulnerability queues sorted by CVSS score are remediating theoretical risk while actual runtime risk waits in the queue. When those teams push back on security tooling as generating too much noise, they’re usually right.
A prioritization system that doesn’t distinguish between CVEs in code that runs and CVEs in code that doesn’t run isn’t a prioritization system. It’s a sorted list.
Runtime Context as the Prioritization Signal
The question that transforms vulnerability prioritization is: is this vulnerable package actually loaded during application execution?
Container CVE risk is not uniformly distributed across a container image’s package inventory. A package that is present in the image but never loaded at runtime cannot be exploited through the application’s code paths. A package that is loaded and participates in processing user requests is reachable and represents genuine risk.
Runtime profiling generates this data: a record of which packages are actually loaded during application execution. When CVEs are evaluated against this data, the prioritization changes immediately:
- CVEs in packages that appear in the runtime execution profile: high priority
- CVEs in packages that don’t appear in the runtime execution profile: deprioritized with documented evidence
The deprioritization isn’t wishful thinking—it’s based on observed execution data. The package wasn’t loaded during a representative profiling exercise. The vulnerable code path isn’t being invoked.
Turning deprioritized CVEs into eliminated CVEs
Container vulnerability scanner output showing which packages are never loaded creates a second option beyond deprioritization: removal. Packages in the container image that the runtime profiling shows are never used are candidates for removal through hardening.
A removed package doesn’t generate CVEs. It doesn’t need to be deprioritized. It doesn’t reappear in next month’s scan output. The remediation is permanent.
This distinction matters at scale: 300 deprioritized CVEs will reappear in next month’s scanner output and require recalibration. 300 CVEs in packages that have been removed from the image don’t reappear.
Practical Steps for Runtime-Informed Prioritization
Integrate runtime profiling data into your vulnerability management workflow. For each CVE in the scanner output, add a “runtime status” field: loaded (in the runtime profile), not loaded (absent from the runtime profile), or unknown (profiling coverage insufficient to determine). This single addition transforms the prioritization process.
Build the runtime status field into your vulnerability tickets. When a CVE creates a ticket, the ticket should include the runtime status. Engineers working the remediation queue immediately know whether they’re working on a CVE in code that executes. This context changes the urgency they apply to remediation.
Route “not loaded” CVEs to a hardening track, not a patching track. CVEs in packages that don’t appear in the runtime profile should trigger a hardening review: can this package be removed from the image? If yes, the remediation is removal, not patching. This is faster, more durable, and eliminates the CVE rather than patching it.
Report CVE counts separately for runtime-loaded and non-loaded packages. The metric that matters for actual risk is the CVE count in packages that are loaded at runtime. Track this separately from the total CVE count. As hardening removes non-loaded packages, the total CVE count drops and the runtime-loaded CVE count becomes the operative metric.
Track false-positive-from-static-analysis rates to calibrate confidence in the deprioritization. The runtime profiling data enables deprioritization decisions that should be validated periodically. Quarterly audits that compare deprioritized CVEs against new threat intelligence about actual exploitation can confirm that the deprioritization model is sound.
Frequently Asked Questions
What is the vulnerability prioritization process?
Vulnerability prioritization is the practice of ranking CVEs by their actual risk to your specific environment rather than treating all findings as equally urgent. Effective prioritization uses runtime context—specifically, whether a vulnerable package is loaded and executed at runtime—to separate CVEs that represent real exploitable risk from CVEs in code that never runs. Without this context, teams default to CVSS scores, which rank theoretical severity rather than actual reachability.
What are the 5 steps of vulnerability management?
A runtime-informed vulnerability management process includes: (1) scanning container images to generate a complete CVE inventory, (2) profiling containers at runtime to identify which packages are actually loaded during execution, (3) correlating the scan output with runtime data to classify CVEs as runtime-present or not-loaded, (4) remediating runtime-present CVEs through patching and routing not-loaded CVEs to a hardening track for removal, and (5) tracking CVE counts in runtime-executed packages separately as the operative risk metric. This process reduces effective remediation queues by 50–80% compared to CVSS-only prioritization.
Which technique is most effective for identifying runtime vulnerabilities in a newly deployed web application?
Runtime profiling is the most effective technique for identifying which vulnerabilities in a newly deployed web application represent genuine risk. By observing which packages are actually loaded during the application’s execution, profiling generates a runtime bill of materials that can be correlated against static scan output. CVEs in packages that appear in the runtime profile are reachable through the application’s code paths and warrant active remediation; CVEs in packages absent from the profile can be deprioritized or eliminated through hardening.
What are the 4 types of vulnerability?
From a container runtime security perspective, the operationally relevant classification is: (1) CVEs in packages loaded at runtime that are exploitable through active code paths, (2) CVEs in packages present in the image but never loaded at runtime, (3) CVEs in packages that can be eliminated by removing unused components through hardening, and (4) CVEs requiring patch management because the affected package is a genuine runtime dependency. This classification is more actionable than traditional CVSS-based categories because it maps directly to remediation actions: patch, deprioritize, or remove.
The Throughput Transformation
Security teams that have added runtime context to their CVE prioritization consistently report the same outcome: the effective remediation queue drops by 50-80%. Not because vulnerabilities went away—because the team is now working on the vulnerabilities that are actually reachable, not the full theoretical exposure list.
This throughput transformation is not cosmetic. Engineering teams that were pushing back on vulnerability management as unmanageable become engaged when the queue contains CVEs that clearly matter. The trust in the security process improves when the CVEs it prioritizes are the ones that, when exploited, would cause actual damage.
The noise problem in CVE management is solvable. Runtime context is how you solve it.
