Introducing the Local Exploit Hazard Model

This model is wrong. Assumptions have been made, biases have been introduced, and tradeoffs were taken.

I'm talking about a paper that I wrote alongside the brilliant Laura Voicu that was born out of the question:

Given my exposed vulnerabilities, what is the likelihood I will experience a material incident involving exploitation?

While we did not end up being able to answer this question fully, we believe that the model and Bayesian framework we have published can give defenders significant insight into where exploit risk resides in their environments.

The paper is a culmination of the work I've been doing over the last 2+ years centered around how to best use EPSS as a defender. Previously, I worked on using the complement product from probability theory to aggregate exploit likelihood to the host while pairing that with qualitative impact information to glean more insight into the vulnerability exploitation risks certain hosts, networks, or departments carry. From there, I dove into basic control effectiveness quantification methods, specifically focused on how well controls perform in preventing vulnerability exploitation.

Partnering with Laura allowed us to extend this idea towards quantifying exploit risk, and while the initial goal was to use this prior research as input into a robust exploit risk quantification model, we just aren't there yet.

Ultimately, we decided on limiting our scope of the paper to modeling exploit hazard. Hazard rates are a concept from survival analysis, and measure the amount of events we can expect in a specified period of time. What we have done in this paper is taken a synthetic organization's mapping of vulnerabilities to assets, their attack vectors from CVSS, their EPSS scores, modeled exploit prevention controls and their attack vectors, and modeled how many exploit events each asset should expect in a given timeframe using Weibull survival analysis of time to known exploitation.

The result is a local exploit hazard rate for each host, or the expected number of global exploit events per day targeting the local vulnerabilities that reside on the host, given exploit prevention controls in place.

Think of this approach as saying: "Given global weather patterns, where is my house currently the most vulnerable to damage, and what can I do about it?"

That rate is computed per vulnerability instance, summed to the host, and summed again to whatever grouping you care about. A subnet. An application. A business unit. The whole company. Hazard rates are additive under independence, so aggregation is addition.

We can also aggregate by known remediation or mitigation action, meaning we can quantify how effective each action is at reducing exposure to global exploit events.

Why a rate and not a score

Most vulnerability prioritization ends at a label. Critical, high, medium. A color on a dashboard. Those labels are ordinal rankings, which means you cannot add them, you cannot project them across a time window, and you cannot check them against reality. Two highs are not a critical.

A hazard rate is a real number with a unit attached. Expected exploit events per day. You can sum it, you can forecast it forward across any horizon, and you can hold it up against the exploitation you actually observed and ask whether the model was close. That is the shift. We are not re-ranking vulnerabilities. We are counting expected events.

Controls are measured, not assumed

EPSS is a global model. It does not know what you have deployed. So before we trust an EPSS score against our own environment, we discount it by how well our controls actually prevent exploitation on that attack vector. A network control only gets credit against network-vector vulnerabilities, a host control only against local ones, and so on.

The catch is that "how well" is not a number anyone knows on day one. So we treat control effectiveness as a probability distribution rather than a fixed value. It starts seeded from expert opinion and updates toward evidence as telemetry, breach and attack simulation, and penetration tests come in. The framework is Bayesian, so the same machinery works whether you have zero data or years of it.

One subtlety matters here that we call out in the paper. Your logs cannot count what they cannot see. A control that silently misses 30% of attempts can look perfect in the logs, because the misses never get recorded. Raw log data drifts toward 100% effectiveness for exactly the controls you should trust least. The expert prior exists to hold that drift back. It encodes what the logs are blind to.

Old vulnerabilities are not fresh ones

A constant hazard rate assumes a vulnerability is as likely to be exploited on day 300 as on day 1. That is not what the data shows. Exploitation activity decays as a vulnerability ages, as attackers move to newer targets and defenders patch.

We model that decay with a Weibull hazard, with the shape calibrated from how long it takes known exploited vulnerabilities to show up in the CISA KEV catalog after disclosure. We know this is an estimation, and account for that using uncertainty ranges in the paper, and noting the expansion opportunity into additional public and private KEV catalogs.

The practical effect is that your aged backlog carries less hazard than a naive constant-rate model would claim, and that changes what rises to the top of the queue. With EPSS and an optional KEV-weight as inputs, this survival model can be refreshed daily if the operator so chooses.

Hazard removed is not volume removed

Here is where I think the work pays off. Because we can aggregate hazard by remediation action, we can rank actions by how much hazard each one removes. And that ranking does not match a count of vulnerabilities fixed, KEVs fixed, or prioritizing by individual EPSS scores.

In our synthetic environment, upgrading OpenSSL on edge services clears fewer vulnerability instances on fewer hosts than a macOS update, and yet it removes almost three times the hazard. The library is network reachable on internet-facing services, where control effectiveness is lowest and EPSS scores are highest. A queue sorted by CVE count misses that. A queue sorted by CVSS severity misses it too. A queue sorted by hazard removed catches it on the first pass.

That is the operational point of the whole model. Do the action that removes the most expected exploit events, not the thing that resolves the most vulnerabilities. Pairing this with qualitative impact labels like I did in my earlier blog can be a powerful view into exploit risk, short of quantifying incident likelihood and loss magnitude.

Where we stopped

We did not get to incident likelihood, and we did not get to financial loss. They are laid out as future work where we map aggregate hazard through to a loss event frequency, and then to a loss exceedance curve in dollars.

We stopped short on purpose. EPSS is global, and the bridge to a specific organization's incident record needs local exploitation telemetry that most of us do not model yet. Putting a dollar figure on top of that gap would have been exactly the false precision this line of work exists to argue against. So the paper ends where the evidence ends.

It's a start

The hazard model stands on its own as a defensible, quantitative basis for deciding what to fix first using publicly and locally available data. It is wrong in the ways every model is wrong. We are explicit about each way in the paper, because a stated assumption is one you can test and replace.

Take it for a spin and let us know where it breaks. The rest is next.

Paper: https://arxiv.org/abs/2607.24618

Reference implementation: https://github.com/t0sche/exploit_hazard_model

"It's the truth I'm after, and the truth never harmed anyone. What harms us is to persist in self-deceit and ignorance."

― Marcus Aurelius, Meditations