I have spent twenty years watching the vulnerability management problem get worse before it got better. In my early years as a principal cloud architect, vulnerability scanning meant running a weekly Nessus scan against a handful of servers, getting a PDF report, and handing it to the ops team to triage. Those were simpler times. Today I work with teams running Kubernetes fleets that produce tens of thousands of CVE findings per scan cycle, and most of them have the same problem: the signal-to-noise ratio is terrible, every finding is labeled “Critical,” and the developers pushing fixes have no idea which vulnerabilities actually matter.
If your vulnerability management program is still triaging CVEs by CVSS score alone, you are doing it wrong in 2026. The tooling and the frameworks have matured considerably. CVSS 4.0 improved on its predecessor. EPSS gives you actual probability estimates. The CISA Known Exploited Vulnerabilities catalog tells you what adversaries are exploiting right now. VEX attestations let you mark non-applicable findings once and stop revisiting them. None of these ideas are brand new, but the integration of all of them into a coherent program is what separates teams that are effectively reducing risk from those that are running exhausted on a CVE treadmill going nowhere.
This article walks through how to build that coherent program.
Why CVSS Alone Fails as a Triage Mechanism
The Common Vulnerability Scoring System was designed to communicate severity, not to tell you what to fix first. A CVSS score answers the question: “If someone exploits this, how bad is it?” It does not answer: “Will anyone exploit this?”
That distinction matters enormously at scale. The NVD publishes tens of thousands of CVEs per year. In any given container image built from a popular base distribution, a scanner like Trivy or Grype will typically surface dozens to hundreds of vulnerabilities. The overwhelming majority of those vulnerabilities have CVSS scores of 7.0 or above, because CVSS scoring incentivizes scoring up. Researchers score for worst-case impact, not typical impact.
The result is that organizations treating every High and Critical as equally urgent are either burning their engineering capacity on fixes that deliver little real-world risk reduction, or they are ignoring the backlog entirely. Neither is acceptable.
CVSS 4.0, released by FIRST on November 1, 2023, addressed several of the framework’s structural problems. The most significant change was retiring the Scope metric, which had been notoriously difficult for analysts to score consistently. CVSS 4.0 replaces it with a dual-impact model: Vulnerable Component impact (VC/VI/VA) and Subsequent System impact (SC/SI/SA). This makes the blast-radius concept explicit rather than relying on a binary flag that most people scored incorrectly. CVSS 4.0 also added Supplemental metrics including Automatable and Safety, which are useful for IoT and OT contexts. The Threat Metric Group in CVSS 4.0 is a cleaner version of the old Temporal metrics.
These are real improvements. But CVSS 4.0 still answers “how bad if exploited” rather than “how likely to be exploited.” For that, you need EPSS.
EPSS: Probability-Based Prioritization
The Exploit Prediction Scoring System, maintained by FIRST.org, does something CVSS does not: it predicts the probability that a publicly disclosed CVE will be exploited in the wild within the next 30 days. Scores range from 0 to 1 and are refreshed daily.
EPSS uses machine learning trained on real-world exploitation data, incorporating CVE characteristics extracted from vulnerability descriptions, temporal signals, and threat intelligence feeds from multiple commercial and open-source sources. Version 4 of the EPSS model, released in March 2025, added richer contextual threat intelligence and demonstrated improved performance on held-out data.
The practical implication of EPSS is that a significant portion of publicly known CVEs have EPSS scores near zero. Many CVSS Critical findings with high base severity will sit at EPSS scores indicating negligible probability of near-term exploitation. Conversely, some findings with moderate CVSS scores will have EPSS scores indicating active exploitation is likely, which is exactly what the CISA KEV catalog tends to confirm after the fact.
The risk quadrant that matters is the combination of CVSS severity and EPSS probability. High CVSS combined with high EPSS is your genuine emergency: the finding is both severe if exploited and actively being targeted. High CVSS with low EPSS is worth tracking but does not justify dropping everything. Low CVSS with high EPSS is a reminder that “severity if exploited” and “likelihood of exploitation” are independent axes. You can have a medium-severity vulnerability that attackers use constantly because it is easy to exploit at scale, automated toolkits for it are widely available, and fixing it gets deprioritized because the CVSS score looks manageable.
The EPSS API is freely available via FIRST.org. You can pull daily scores for any CVE list and integrate them into your triage pipeline. Every major scanning tool, from Trivy to Grype to Wiz to Tenable, has incorporated EPSS data. If you are not enriching your findings with EPSS scores today, you are making prioritization decisions with half the picture.
The CISA KEV Catalog: Exploitation Confirmed
EPSS gives you probability estimates. The CISA Known Exploited Vulnerabilities catalog gives you ground truth: these are vulnerabilities with confirmed active exploitation in the wild. CISA updates the catalog continuously. In June 2026, for example, CISA added 23 vulnerabilities to the KEV catalog. When something lands in KEV, attribution moves from “EPSS says 70% probability” to “adversaries are using this right now.”
CISA’s Binding Operational Directive 22-01, issued in November 2021, requires US federal civilian executive branch agencies to remediate KEV vulnerabilities within defined timeframes. The principle extends well beyond government: if an attacker has a reliable exploit for a KEV vulnerability and you have that vulnerability in your exposed infrastructure, the question is not if you will be targeted but when.
Any vulnerability management program worth the name should have a fast-path remediation lane for KEV entries. I recommend a 72-hour patch window for KEV vulnerabilities in internet-exposed systems and a 14-day window for internal systems. These SLAs need to be defined in policy, tracked in tooling, and escalated automatically when breached. The CISA KEV catalog is available as a JSON feed from CISA, making automated ingestion trivial.
VEX: Suppressing Findings You Have Analyzed
One of the underappreciated contributors to CVE fatigue is findings that are technically present but functionally not exploitable in your specific build. A classic example: your container image builds from an Alpine base that includes a library with a CVE, but your application never calls the vulnerable code path, or the affected feature is not compiled into your build, or you are running on an architecture where the vulnerability does not apply.
A scanner cannot determine this automatically. It sees the package, it checks against the vulnerability database, and it reports the finding. This is correct behavior. The problem is that engineers spend time re-triaging the same false-positive findings across every scan cycle.
VEX (Vulnerability Exploitability eXchange) is the mechanism for documenting these analyses once and having them respected by downstream tools and consumers. CISA published minimum requirements for VEX documents. OpenVEX, an implementation from the Open Source Security Foundation, specifies a minimal JSON-LD format that captures VEX status for a given product and CVE combination. VEX status values include “not affected” with a justification reason, “affected,” “fixed,” and “under investigation.”
The workflow is: your security team analyzes a finding, determines it is not applicable in your deployment (function never called, vulnerable code path unreachable, component not present at runtime), and produces a VEX document asserting that status. Your CI/CD pipeline and your scanning tooling ingest the VEX document and suppress that finding in future reports for that product version. The next time the scanner runs and sees the same package, it checks the VEX assertions and omits the suppressed finding from the actionable triage queue.
VEX does not make a finding disappear forever. If your product changes in a way that might activate the vulnerable code path, you need to revisit the VEX assertion. But for stable, well-understood components, VEX is a significant reduction in recurring triage noise.
The integration of VEX with SBOM is natural: an SBOM documents what is in your build, and VEX documents which of those components’ known vulnerabilities are or are not applicable. The two artifacts together give a security consumer a complete picture. I wrote about SBOM and supply chain attestations in detail in our software supply chain security guide, and SLSA build provenance is the third leg of that stool.
Building Your Triage Pipeline
With EPSS, KEV, and VEX as inputs, the triage pipeline looks like this:
Every finding that comes in gets enriched with EPSS score and KEV status. KEV entries skip the normal queue entirely and go directly to the emergency remediation lane. Non-KEV findings are then triaged by the combined CVSS plus EPSS signal. A finding with CVSS 9.0 and EPSS 0.001 goes into the medium-priority queue: monitor and patch in the next regular maintenance cycle. A finding with CVSS 7.0 and EPSS 0.85 goes into the high-priority queue despite the lower severity score, because that exploitation probability is a real signal.
After the initial triage pass, findings that are technically present but have been analyzed as non-exploitable in your specific deployment get tagged for VEX documentation. A security engineer reviews the analysis, documents the justification, and the VEX assertion is published alongside the SBOM for that artifact version. On subsequent scans, those findings are automatically suppressed.
What remains after this pipeline is a genuinely actionable queue. The findings that need remediation attention are the ones where someone exploiting the vulnerability is realistically plausible (high EPSS or confirmed KEV), the impact in your environment is significant (CVSS severity after environmental adjustment), and the finding is not already documented as non-applicable (no VEX assertion).
The Tool Landscape
For scanning infrastructure, the open-source tooling is excellent. Trivy and Grype are both solid container and filesystem scanners that integrate EPSS and KEV data alongside CVSS scores. Both are actively maintained, integrate naturally into CI/CD pipelines, and produce output that can be consumed by aggregation tools. If you are building a custom pipeline, start with one of these.
Wiz has built what they call Unified Vulnerability Management, positioning it as a single platform that ingests findings from multiple scanners and adds cloud context including attack path analysis and runtime reachability. The value proposition is that a vulnerability in a package that is never loaded at runtime is a different risk than the same vulnerability in a package sitting on an internet-facing service that has already been misused to gain initial access. Wiz’s Security Graph connects vulnerability findings to cloud posture findings to identity and access data, which genuinely changes what “risk” means. Context is the thing that CVSS scores cannot capture on their own.
Snyk’s strength has always been the developer integration: findings surfaced in the IDE, in pull request checks, in CI/CD pipelines, as close to the point where the fix is cheapest. The 2026 Snyk 2.0 platform rollout added a unified asset inventory and improved exploitability context. Snyk’s Transitive AI Reachability feature attempts to determine whether a vulnerable function in a deep transitive dependency is actually callable from your application code. This is directly analogous to what runtime reachability analysis does for deployed containers.
For teams with significant compliance requirements, Tenable and Qualys still own enterprise accounts with decades of vulnerability database curation and the audit trail requirements that come with SOC 2 and ISO 27001 programs. We covered the compliance-as-code side of these programs in our compliance automation guide.
Vulnerability SLAs and Enforcement
The vulnerability management program falls apart without enforced SLAs. Scanning and triaging findings that never get remediated is theater. I have seen teams spend enormous energy building beautiful dashboards showing thousands of open vulnerabilities aging indefinitely because there is no accountability mechanism.
SLAs need to be differentiated by severity tier and exposure context. Here is a framework that has worked for me:
KEV entries in internet-exposed systems get a 72-hour remediation SLA with mandatory security team involvement and escalation to engineering leadership if not met. KEV entries in internal systems get 14 days. CVSS Critical plus high EPSS (above 0.5) findings in internet-exposed systems get 14 days. CVSS Critical plus high EPSS in internal systems get 30 days. All other CVSS Critical findings get 30 days for internet-exposed, 60 days for internal. High-severity findings follow a similar pattern with longer windows. Medium and Low findings go into the technical debt backlog reviewed monthly.
The SLA framework only works if it is tracked in tooling and the exceptions are deliberate and documented, not silent. Every finding that breaches an SLA should trigger an escalation notification. Every accepted exception should require documented justification and a new target date. Without that enforcement, SLAs are aspirational at best.
This framework also requires you to actually know what is internet-exposed. Wiz, and to a lesser degree most CNAPP platforms, handle this by querying your cloud configuration directly. They know which compute has a public IP, which containers are behind a load balancer with an internet-facing listener, which functions are exposed via API gateway. That context is fundamental to applying differentiated SLAs correctly.
Our CNAPP guide covers how modern platforms combine vulnerability management with cloud security posture management, and that integration is where the internet-exposure context comes from.
Container Fleets and the Immutable Image Problem
Container vulnerability management has a structural complication that bare-metal or VM environments do not: your attack surface is almost entirely defined by your base images, and updating a base image requires rebuilding and redeploying every application that uses it.
This creates pressure toward one of two anti-patterns. The first is “fix on rebuild”: teams only update base images when they happen to be rebuilding for other reasons, which means vulnerability age grows between deployments. The second is constant churn: automated systems that trigger base image rebuilds constantly generate a stream of deployments that overwhelm review processes and introduce regressions.
The right answer sits between these extremes. Build a pipeline that monitors your base images for new CVE-scored-over-threshold findings and triggers a rebuild when the aggregate risk crosses a defined threshold. Do not trigger on every new CVSS 5.0 finding; trigger when you have a new KEV entry or a new high-EPSS critical finding. Combine this with tooling that makes base image rebuilds and redeployments as low-friction as possible.
Chainguard and Distroless images help at the source: a smaller base image has fewer packages and therefore fewer CVEs. We covered this approach in detail in our container image hardening guide. The combination of minimal base images plus EPSS-driven rebuild triggers plus VEX assertions for analyzed non-applicable findings is genuinely manageable at fleet scale.
Secrets and Vulnerability Management Are Related Problems
One pattern I see repeatedly is organizations that have a mature vulnerability management program but a weak secrets detection posture, or vice versa. These are related problems with related tooling. A leaked API key in a repository is not a traditional vulnerability, but it is exploited the same way: automated scanning finds it, and an attacker uses it before the rotation window closes. The triage principles are similar: exposure context matters, time-to-remediation SLAs matter, and the findings need to flow into the same engineering accountability system. We covered the secrets detection side in our Gitleaks, TruffleHog, and GitGuardian guide.
The Reporting Layer
The program needs a reporting layer that communicates meaningfully to both engineering teams and leadership. For engineering teams, the useful view is: here are the findings assigned to my systems, here is the SLA status for each, here are the ones that are past due. For leadership, the useful view is: what percentage of our fleet has a KEV vulnerability with no remediation started, what is our mean time to remediate by tier, how is our SLA compliance trend moving.
Neither of these is the “20,000 open CVEs” dashboard that generates existential despair without actionable direction. The EPSS-filtered, KEV-enriched, VEX-suppressed queue is what drives the engineering view. The aggregated SLA compliance metrics are what drives the leadership view. These are different outputs from the same underlying data, and building both matters for program health.
Operationalizing the Program
Getting from “we have a scanner” to “we have a vulnerability management program” requires organizational infrastructure beyond tooling. Someone needs to own the program, not just the tooling. The owner needs authority to enforce SLAs and escalate breaches. Engineering teams need to understand the prioritization logic so they trust the queue and do not feel like they are playing whack-a-mole with arbitrary requirements.
The initial rollout I recommend is: start with KEV-only hard SLAs, because the urgency is defensible and the queue is small enough to be tractable. Get the accountability muscle working before expanding to the broader EPSS-tiered program. Run the full program in monitoring-only mode for a quarter to calibrate your SLA targets against your actual remediation capacity. Then enforce.
Most teams discover in that calibration quarter that their KEV remediation for internet-exposed systems is better than they expected (because those findings are hard to ignore when they make the news), their critical-with-high-EPSS remediation is mediocre, and their backlog of aging medium findings is essentially unlimited. That is a useful diagnostic. Fixing the critical-with-high-EPSS category is where the real risk reduction lives.
Pair this with the Kubernetes security hardening work covered in our CIS benchmarks and Pod Security Standards guide: hardened runtime configuration reduces the blast radius of vulnerabilities that do get exploited, which is the defense-in-depth layer that matters when you cannot remediate fast enough.
Getting Started Today
If I were starting a vulnerability management program from scratch today, the first 30 days would look like this: deploy Trivy or Grype into your CI/CD pipeline with EPSS enrichment enabled; identify every KEV entry in your current fleet and set a hard date to remediate them all; define your tiered SLA policy based on CVSS-plus-EPSS with explicit escalation paths; pick one CNAPP (Wiz is the obvious choice for cloud-native, Snyk for developer-integrated coverage) and integrate it with your ticket system so findings auto-create issues with SLA due dates; and run your first VEX exercise on the top five recurring false-positives to demonstrate the suppression workflow.
That 30-day foundation does not require solving everything. It establishes the prioritization logic, the KEV accountability muscle, and the VEX workflow. The rest is iteration. The teams that have effective vulnerability management programs in 2026 are not the ones that bought the most expensive scanner. They are the ones that built the prioritization logic and the organizational accountability to act on it. The tooling is solved. The human system is where the work is.
Get Cloud Architecture Insights
Practical deep dives on infrastructure, security, and scaling. No spam, no fluff.
By subscribing, you agree to receive emails. Unsubscribe anytime.