Vulnerability prioritization is the process of deciding which security weaknesses should be investigated and remediated first. Most programs already use more than CVSS. They add EPSS, CISA Known Exploited Vulnerabilities, asset criticality, internet exposure and available patches. Yet one important factor still gets flattened: time.
A CVE does not carry the same evidence profile throughout its life. An advisory appears. EPSS moves. A public proof of concept is published. Researchers begin discussing exploit behavior. CISA may later add the vulnerability to KEV. The risk decision made on Monday should not be based on the same evidence available three weeks later.
That sounds obvious. In practice, many vulnerability models and many evaluations treat evidence as if it arrived all at once.
New research called ThreatLens: Evidence-Guided Ranking of High-Priority CVEs offers a useful way to think about the problem. Its most important contribution is not another score. It is a more realistic definition of the prioritization task.
What ThreatLens found
ThreatLens evaluates CVEs at weekly decision points using only evidence available by that date. The framework combines signals including CVSS data, EPSS scores and movement, GitHub Security Advisory activity, public exploit information and vulnerability recency.
The researchers trained the model on earlier vulnerabilities and tested it on later, distinct CVEs. This matters because a model evaluated with information published after the prioritization date may look accurate while being impossible to use in the real world.
On the held-out test set, ThreatLens surfaced 80 percent of CVEs that would later enter CISA KEV within its top 20 results. At the same review budget, its recall was more than three times higher than EPSS alone. It identified 95.9 percent of future KEV entries within its top 50.
These are the authors’ reported findings, not proof that the model will reproduce the same performance in every enterprise. KEV is an incomplete record of exploitation. It reflects confirmed activity, reporting practices and CISA’s operational criteria. The paper also evaluates global exploitation relevance, not the business impact of a CVE inside a specific customer environment.
Those limits do not weaken the central lesson. They clarify it: exploit relevance and organizational risk are separate layers, and both change over time.
Why CVSS, EPSS and KEV should not compete
Security teams often talk about CVSS, EPSS and KEV as if one must replace the others. That framing creates unnecessary arguments.
CVSS describes the technical characteristics and potential severity of a vulnerability. EPSS estimates the probability of observed exploitation activity within the next 30 days. KEV records vulnerabilities for which CISA has evidence of exploitation in the wild. None of the three answers the complete operational question: what should this organization fix first today?
The answer also depends on whether the affected asset exists in the environment, whether it is exposed, what business process it supports, which controls surround it, and whether a safe remediation is available.
ThreatLens suggests a better mental model. Treat each external signal as evidence with a timestamp, then combine it with current environmental context. A ranking should evolve when the evidence changes.
This is a stronger foundation for risk-based vulnerability management than any single universal score.
Prioritization is a queue, not a label
Security tools tend to classify vulnerabilities as critical, high, medium or low. Operations teams do not work in four abstract buckets. They work through queues under fixed constraints.
A vulnerability analyst may have time to examine 20 new CVEs. An infrastructure team may have one maintenance window and capacity to deploy five changes. A business owner may approve an emergency action only when exploitation evidence crosses a defined threshold.
The ThreatLens researchers therefore frame prioritization as a ranking problem under an analyst review budget. This is closer to how remediation actually works. The objective is not to perfectly label every CVE. It is to place the most consequential decisions near the top of a limited queue.
That shift has product implications. A useful vulnerability platform should show why an item moved, which new evidence changed its position and what action is now possible. A score without history leaves analysts guessing whether urgency increased because of new exploitation activity, a change in asset context or a recalculated model.
What time-aware prioritization should look like
A practical model needs four layers.
1. Technical severity: What could exploitation allow an attacker to do?
2. Threat evidence: Is exploitation predicted, demonstrated or observed?
3. Environmental exposure: Is the vulnerable software present, reachable and important to the business?
4. Remediation readiness: Is there a validated patch, mitigation, configuration change or compensating control available?
Each layer should retain its evidence and timestamp. This makes the result explainable and auditable. It also prevents an important mistake: using present-day knowledge to justify an earlier decision.
For Vicarius, this research supports the direction behind vScore, where exploitability, context and business impact inform prioritization. The next strategic opportunity is to make time more visible. Users should be able to understand not only why a vulnerability is ranked highly, but why its urgency changed since the previous assessment.
That ranking should lead directly to action. Vicarius patch management connects prioritized CVEs with the patches that close them on each asset. When no patch is appropriate, the platform can surface alternative remediation paths instead of leaving the user with a better ordered backlog.
How to evaluate a prioritization model honestly
Security buyers should ask vendors how their risk models are tested. A strong evaluation should answer four questions:
1. Did the model use only information available at the decision date?
2. Were the training and test CVEs kept separate?
3. Was performance measured within realistic review or remediation budgets?
4. Was global exploit likelihood separated from customer-specific business risk?
Without these controls, impressive accuracy can hide temporal leakage. A model may be predicting yesterday with tomorrow’s evidence.
Organizations should apply the same discipline internally. When reviewing a missed priority, reconstruct what was known at the time. Do not blame an analyst for failing to act on evidence that had not yet appeared. Instead, ask whether the process responded quickly enough when the evidence changed.
The real goal is faster risk reduction
Time-aware vulnerability prioritization is not about producing a more sophisticated dashboard. It is about shortening the path between a meaningful change in evidence and a safe remediation decision.
ThreatLens shows that multiple modest signals can become much more useful when they are aligned in time and evaluated realistically. The strongest model in the paper was not the largest neural system. A structured logistic ranker performed best. Good data discipline mattered more than model spectacle.
That is the message security leaders should carry forward. Better prioritization does not begin with a bigger AI claim. It begins with trustworthy evidence, current context and a direct path to remediation.
Ready to bring time-aware, context-driven prioritization to your vulnerability program? Request a demo to see it in action.
Frequently asked questions
What is time-aware vulnerability prioritization?
Time-aware vulnerability prioritization ranks CVEs using only the evidence available at the current decision point. It updates the ranking as exploit intelligence, advisories, asset context and remediation options change.
Is EPSS enough to prioritize vulnerabilities?
No. EPSS estimates near-term exploitation probability, but it does not measure business impact, asset exposure or remediation feasibility. It is most useful as one signal within a broader contextual model.
Why is CISA KEV not a complete ground truth?
KEV contains vulnerabilities with confirmed exploitation that meet CISA’s inclusion criteria. Some exploited vulnerabilities may not be reported or added, and organization-specific risks may never appear in the catalog.
.webp)
%20Signals%20a%20New%20Era%20of%20Supply%20Chain%20Risk.webp)
.webp)
%20to%20Reduce%20Attack%20Surface.avif)
