Where to start: The maturity path from static scoring to prediction

The idea of a local predictive model can be daunting, particularly if you’re still at the stage of patching by pivoting off KEV or CVSS. But if it feels like miles away to have your own local predictive engine, remember the old axiom: the journey of a thousand miles begins with a single step. Most teams arrive at a true predictive approach to exposure management in stages rather than all at once.

And each stage represents a quantum leap forward. So where should you start?

Stage zero: patching by severity

Many vulnerability programs still run on CVSS. It’s probably a familiar process to anyone who has wielded a scanner: reveal hundreds or thousands of "Critical" and "High" findings, most of which will never see an exploit, sitting next to a handful of unglamorous mediums that are actually the ones being hit in the wild. Teams patch the flashy ones first because the scanner told them to. The teams doing the patching complain and ask for data to prove what they’re doing matters. Many patches go undone and everyone goes to the bar to complain about the entire ordeal. Trauma ensues.

It’s not a big secret that CVSS is a severity score pretending to be a priority score, and the gap between those two inputs is where most patching effort gets wasted.

Step one: EPSS — probability instead of guesswork

The first step to weaning the team off CVSS doesn't require a vendor relationship or a data pipeline. It simply requires adopting EPSS, the open, free Exploit Prediction Scoring System that Empirical Security helped create and continues to maintain and update.

EPSS asks a different question than CVSS. Instead of "how bad could this be," it asks "how likely is this to be exploited in the next 30 days," and answers with a calibrated probability. It's not perfect because it's a population-level estimate, built from the internet's behavior in general. However, it helps guide teams along the path from “static severity score” to “exploit probability.” And it has the advantage of being, you know, free.

For a team that's never touched anything but CVSS, layering EPSS on top is the cheapest, fastest way to start separating "scary-looking" from "actually dangerous." 

Step two: risk-based vulnerability management — threat intel at scale 

EPSS gets you some version of a probability. The next step is building an operational practice around it, pulling in a broader set of threat intelligence such as exploitation telemetry, GitHub proof-of-concept code, malware associations, and threat actor activity. Teams can use this expanded portfolio of threat intelligence to drive prioritization continuously, not as a one-time scoring exercise.

This is what the industry has come to call risk-based vulnerability management, or RBVM. It's not new. The founders of Empirical Security helped invent the category years ago with their previous company, Kenna Security, and Empirical's founders (Jay Jacobs, Michael Roytman, Ed Bellis) were building it before EPSS existed as an open standard. What makes it a real step up from raw EPSS is cadence and breadth, providing near-real-time intel instead of a static snapshot as well as a wider net of exploitation evidence rather than a single feed.

This is what Empirical's Foundation model does. Compared to EPSS, it’s trained on a much larger, faster-moving dataset (Empirical's global exploitation dataset covers over 180,000 CVEs, roughly 5x the size of any other vendor's data set) and updated hourly rather than daily.

The point isn't just "more data." It's that exploitation is a red flag that becomes less meaningful over time: a vulnerability attacked yesterday is far more likely to be attacked again this week than one that hasn't been touched in months. You need to be working from a feed that’s alive, not one that’s stale and out of date by the time your team touches it. In doing so, your ability to prioritize potential threats becomes significantly stronger. 

Step three: the local model — your environment, not the Internet's

Everything up to this point — CVSS, EPSS, global RBVM — answers a version of the question "is this CVE dangerous?" None of it answers "is this CVE dangerous here." Your organization is not the internet at large. It has its own stack, its own scan history, its own detections, and its own blind spots.

A local model is trained on an organization's own vulnerability scanner data, cloud security, configurations, and asset inventory, producing a score calibrated to that organization's actual risk surface. The payoff is a tighter, more defensible priority list, and a real answer to the question every IT team eventually asks: why is this a priority for us specifically? Local models are also private by construction, keeping both the model and the data in-house.

There is some complexity to the local model (which is called Radiant in the Empirical Security world). Having a local model presumes you already have clean asset data, a mature scanning practice, and a team ready to defend a model's output to a regulator or a board. It also presumes some size (several thousand employees) so there’s a sufficient quantity of data to feed the model. That’s why Radiant is at the end of the maturity curve, not the beginning.

Every Step Matters

You can move up the maturity curve by starting with small changes. CVSS to EPSS is a relatively minor process adjustment that nevertheless can have a significant impact on your team’s effectiveness. EPSS to global risk-based vulnerability management is a maturity step most teams can make within a quarter.

Building and operationalizing a local model is the step that requires the most organizational readiness — and it should be taken when you’re at the size and stage that you’re ready to tell the board what threats are specifically targeting your organization, not your neighbor’s.

Ready to start, even at the global model level? Reach out to us.