Introduction to LEV

Overview

In this section we introduce NIST Likely Exploited Vulnerabilities (LEV)

• what it is and what it adds to vulnerability management
• why it matters for day-to-day prioritization
• how to apply it alongside EPSS and KEV

Source Code is a clean-room implementation of the LEV source code i.e. from the whitepaper only. It is not associated with the LEV paper authors.

What is LEV?

Likely Exploited Vulnerabilities (LEV) is a probabilistic score proposed by NIST to estimate the chance that a published vulnerability (CVE) has already been exploited in the wild.

A high-performance Python implementation of: Mell P, Spring J (2025) NIST CSWP 41: "Likely Exploited Vulnerabilities: A Proposed Metric for Vulnerability Exploitation Probability". (National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity White Paper (CSWP) NIST CSWP 41. https://doi.org/10.6028/NIST.CSWP.41

Why LEV Matters

KEY INSIGHT: LEV gives an additional View of Vulnerability Risk

LEV fills a gap by looking backward in time, complementing forward-looking and current exploitation data:

	Past	Future
Exploited	CISA KEV
Probability of Exploitation	LEV (past probability)	EPSS (next 30 days)

The diagram above is an extract from Risk Remediation Taxonomy Detailed.

CISA KEV is a list of vulnerabilities that have been exploited in the wild (past).

• It contains a subset of known exploited CVEs
• Typically, once a vulnerability is added to a KEV list, it stays on the list permanently

EPSS is the probability of exploitation in the next 30 days (future).

• It is suited to network environments and may have False Negatives

LEV gives a probability of exploitation in the past

• LEV can be used to augment CISA KEV i.e., shortlist candidates for addition to KEV (with other qualifying factors e.g., industry evidence)
• LEV works backwards—compounding historical EPSS scores—to quantify past exploitation probability
  • The longer and more consistently a CVE has high EPSS scores, the higher its LEV, reflecting real-world attacker behavior
• In practice:
  • It needs to be validated against real evidence of exploitation data to understand it, validate it, and calibrate it
  • The LEV list should be made available directly - or used to augment the KEV list

As a general user, how do I use LEV?

You don't:

• The LEV list is not officially published as of June 1, 2025. And even if it were, the LEV list by itself is not that useful for a general user i.e., there isn't a user guide, there isn't validation of the data
• General users who use CISA KEV may benefit from LEV by additional validated entries being added to KEV per use case "augment KEV based vulnerability remediation prioritization by identifying higher-probability vulnerabilities that may be missing"

LEV inherits some characteristics of EPSS

Because LEV is based on EPSS only, the same points about Applying EPSS to your environment apply to LEV also.

LEV use cases

The LEV probabilities have at least four use cases:

1. measure the expected number and proportion of vulnerabilities, as identified by Common Vulnerability and Exposures (CVE) identifiers, that actors have exploited,
2. estimate the comprehensiveness of KEV lists,
3. augment KEV based vulnerability remediation prioritization by identifying higher-probability vulnerabilities that may be missing, and
4. augment EPSS based vulnerability remediation prioritization by identifying vulnerabilities that may be underscored.

NIST CSWP 41: "Likely Exploited Vulnerabilities: A Proposed Metric for Vulnerability Exploitation Probability"

How LEV Works

KEY TAKEAWAY: LEV's Backward-Looking Algorithm

LEV essentially asks: "Given all the historical EPSS scores, what's the probability this vulnerability was exploited at some point in the past?"

1. Windowing EPSS

   • EPSS(v, dᵢ) gives the probability of exploitation in the 30-day window starting at date dᵢ

2. Non-Exploitation Probability

   • For each window, compute (1 − EPSS × window-fraction)

3. Compound Across Time

   • Multiply all "no-exploit" probabilities from first EPSS release (d₀) to today (dₙ)

4. Flip to Get LEV

   • LEV = 1 − ∏₍windows₎(no-exploitProbability)

This approach treats each EPSS window as evidence that exploitation may already have occurred, with longer exposure driving LEV toward 1.0.

Applying LEV in Vulnerability Management

LEV outputs a daily, per-CVE probability of past exploitation along with supporting history, enabling:

1. Measuring Exploited Proportion

   • Estimate how many CVEs have likely been weaponized to date

2. Assessing KEV Coverage

   • Compute a lower bound on how many CVEs a KEV list should include, revealing gaps

3. Augmenting KEV-Driven Remediation

   • Flag high-LEV CVEs missing from KEV for review or urgent patching

4. Strengthening EPSS-Driven Prioritization

   • Combine LEV with EPSS (and KEV overrides) in a Composite Probability: max(EPSS, KEV_flag, LEV)
   • Ensures previously exploited CVEs receive top attention

---

Concerns

Misunderstanding of EPSS?

CRITICAL INSIGHT: Past vs. Future Exploitation

NIST CSWP 41 suggests that EPSS provides inaccurate scores for previously exploited vulnerabilities, and recommends changing the EPSS scores to be 1.0 for all vulnerabilities on a KEV list.

This logic is fundamentally flawed because EPSS is the probability of exploitation in the next 30 days, and EPSS analysis data shows that past exploitation does not guarantee exploitation in the next 30 days.

EPSS is the probability of exploitation in the next 30 days (future).

CISA KEV is a subset of vulnerabilities that have been exploited in the wild (past) and the vulnerability typically stays on the list regardless of exploitation thereafter.

Just because a vulnerability was known exploited, does not mean it will be exploited in the next 30 days.

Jay Jacobs (EPSS) has shown detailed analysis of exploitation patterns over time to validate this. See sections:

• "What's The Typical Pattern Of Exploitation Activity?"
  • Don't treat "Exploited" as a binary variable; intensity and duration matter for prioritization
• "What's The Ratio Of New Vs. Old Exploitation?"
  • Newly exploited vulns get the most attention, but the older ones get the most action
• "How Long Since Exploitation Was Last Observed?"
  • Just because a vulnerability is known to have exploitation activity, doesn't mean it always will

This Risk Based Prioritization guide has already covered the misunderstanding where users requested to "set the EPSS score to 1 if there are already published exploits" per EPSS as the Single Score for Exploitation.

NIST CSWP 41 May 19, 2025

However, as discussed in Sec. 2.2 and more thoroughly in Sec. 5.1, EPSS provides inaccurate scores for previously exploited vulnerabilities. It is also not currently possible to fix inaccurate scores in EPSS.

A mathematically defensible solution is obtainable if the goal is changed to include remediation of previously exploited vulnerabilities and a comprehensive KEV list is available. To do this, change the EPSS scores to be 1.0 for all vulnerabilities on a KEV list.

The addition of LEV probabilities is a practical solution that can overwrite remaining inaccurate EPSS scores. It DOES NOT guarantee to remove all EPSS errors (only a comprehensive KEV list does that, which is a property that can be measured using LEV).

LEV2 Approximation

Invalid Probability Division

The "Small Probability" approximation is not valid for higher EPSS scores (the scores of interest), and is not necessary if the computation is optimized per the Source Code provided here.

• Rigorous vs NIST approximation time ratio: 2.23x

LEV handles EPSS scores as covering only a single day by dividing them by 30: \(P_1 \approx P_{30}/30\)

Dividing a 30-day probability by 30 to get a 1-day probability generally does not make sense in a rigorous probabilistic context.

An example run of the code from EPSS to 2023-3-7 to 2025-5-31 showed that this approximation resulted in +674 vulnerabilities (+1.57%) less than the rigorous approach.

P30 is the EPSS Score (Probability of exploitation for the next 30 days)

Probabilities are not linear over time in this way. If you have a probability \(P_{30}\) of an event occurring over 30 days, it doesn't mean the probability on any single day is \(P_{30}/30\).

The "Small Probability" approximation: The approach (dividing by 30) only makes sense as a rough approximation when the EPSS scores (which represent 30-day likelihoods) are very small (which is true for most but not all scores, where the ones we care about are high scores):

• If \(P_1\) is very small, then \((1 - P_1)^{30} \approx 1 - 30P_1\) (using the binomial approximation or first-order Taylor expansion for \((1-x)^n \approx 1-nx\) when \(x\) is small)
• In this case, \(P_{30} = 1 - (1 - P_1)^{30} \approx 1 - (1 - 30P_1) = 30P_1\)
• So, if \(P_{30} \approx 30P_1\), then \(P_1 \approx P_{30}/30\)

This appears to be the underlying assumption for the deliberate simplification made in the NIST formula - likely for computational efficiency.

Quote

The LEV2 equation requires significantly more computational resources. It handles EPSS scores as covering only a single day by dividing them by 30 (instead of each score covering a 30-day window). This enables the equation to incorporate far more EPSS scores within the computation and increases the equation's responsiveness to changing scores (especially for newly released vulnerabilities).

Tip

Using standard concurrent processing per the source code, the approximation is not required on a standard computer.

The code to calculate LEV (both approximation and rigorous), and the composite probability (both approximation and rigorous) completes in less than 30 minutes on a standard computer.

• The approximation calculations are not required but in the code for comparison.
• See example log file: https://github.com/RiskBasedPrioritization/LEV/blob/main/logs/20250531_180156.log

Calculations for new days (new runs) can be very fast if the code is optimized to use existing calculations from previous runs (it isn't currently).

Independent Events Assumption

Attacks Aren't Random

The Independent Events Assumption is not valid.

Independent Events Assumption: If we assume the events (vulnerabilities being exploited) are independent day-to-day, then the probability of not being exploited over 30 days would be the product of the probabilities of not being exploited on each individual day.

• Let \(P_1\) be the daily probability of exploitation
• The probability of not being exploited on a given day is \((1 - P_1)\)
• The probability of not being exploited over 30 days is \((1 - P_1)^{30}\)
• Therefore, the probability of being exploited over 30 days is \(1 - (1 - P_1)^{30}\)
• If you're given \(P_{30}\) (the 30-day likelihood), you'd solve \(P_{30} = 1 - (1 - P_1)^{30}\) for \(P_1\). This is a much more complex calculation than simple division

The Independent Events Assumption is not valid because:

• The EPSS data shows that signature detections do have patterns and are not entirely independent events. See detailed analysis of exploitation patterns over time.
• Attacks driven by people have patterns e.g., a persistent threat, periodic probing of targets

EPSS Scores as Lower Bounds Rationale

Rationale is lacking for EPSS Scores as Lower Bounds

"While EPSS scores assume that a vulnerability has not been observed to be exploited in the past".

• The EPSS model or score is not making this assumption.
• This is not the same as the EPSS model not using past exploitation data directly to feed the model.

The "EPSS Scores as Lower Bounds" rationale from the NIST CSWP 41 paper basically says: "If the EPSS IDS data sees an actual attack attempt (so true positive in the validation data), the EPSS score is not set to 1 for that day. So the EPSS score on that day is an under-estimate."

Takeaways

KEY TAKEAWAYS

What LEV Gets Right:

1. LEV estimates the likelihood a CVE has already been exploited in the wild
2. It leverages and compounds historical EPSS data for evidence-based prioritization
3. Use LEV to measure exploited CVE proportions, evaluate KEV comprehensiveness, and enhance both KEV- and EPSS-driven workflows
4. Combined with continuous validation (e.g., breach-and-attack simulations), LEV helps close the gap between theoretical risk and real-world exploitation

What to Watch Out For:

1. Mathematical approximations may not hold for high EPSS scores (the ones you care about most)
2. Independent events assumption doesn't reflect real attack patterns
3. Past vs. future confusion - don't assume past exploitation guarantees future exploitation
4. Limited validation - LEV needs real-world calibration before widespread adoption