"Why the hell didn't we fix that?"
I was at a conference this week when a CISO walked up to me and cut straight to it. The only thing he really cares about, he said, is what he's going to tell the board after they get popped.
You know how this goes: the breach is public, the board is in the room, and someone is yelling, "Why the hell didn't we fix that vulnerability?" That's the end point of every vulnerability management program, much more than the dashboard or the monthly patch report.
So the question isn't just which vulns should we fix. It's: can you defend the ones you didn't?
From CVSS to RBVM
For years the playbook went like this: pull the CVEs out of your scanner, sort by CVSS, and start at the top.
Of course you already know the problems with CVSS, which offers up a static, point-in-time score that’s assigned once, telling you severity and how much damage a vuln could do. It tells you nothing about whether an attacker cares about it, or whether anyone can even exploit it. Yadda yadda yadda.
But Ed Bellis and Michael Roytman came along with Kenna Security and said there had to be a better way. Instead of a severity score, use data, and lots of it: threat intel, exploit intel, what attackers are actually doing in the wild. That became risk-based vulnerability management, and a whole category of tools followed (Kenna and plenty of others).
RBVM was a huge leap. It moved us from "how bad could this be?" to "how likely is this to be used against me?"
The problem never fully went away
We still need a better way to prioritize, but now we also need a better way to defend what we're prioritizing, and what we're choosing not to remediate.
AI is making that harder. Attacks can be more random and more sophisticated than ever, which means "we followed the score" is a thinner shield than it used to be. When the board asks why, "the tool said so" isn't an answer. You need to be able to explain the reasoning behind your strategy, and the trade-offs you knowingly made.
Why 9? Why not 8.8?
Let's make it concrete. Say I'm a CISO and my strategy is Tenable VPR 9 and above. Every vuln scoring 9+ is on my team's list. That's the goal: patch everything above the line.
Now the uncomfortable questions:
Why 9? Why not 8.8? Why not 9.2?
Why not 7, for that matter?
What actually happens if I move the line? Beyond "more vulns" or "fewer vulns," what am I gaining or giving up?
Most teams can't answer these; the threshold was picked because it felt right, or because it produced a list the team could realistically get through. It’s the kind of answer that falls apart in front of a board after an incident.
What it costs to move the line
One thing I learned fast when I started at Empirical: data scientists are WIZARDS. And they figured out a way to confidently answer, what are the consequences of changing my risk tolerance threshold?
Say I drop my threshold by 2 points (just as an example). Empirical shows me the difference in three terms:
Coverage: of the vulns that actually get exploited, how many does my threshold catch?
Efficiency: of the vulns I'm remediating, how many actually mattered?
Effort: how many vulns does my team now have to fix to hit the goal?
That turns "we patch 9 and above" into a decision with known trade-offs. You can say what you're covering, what you're knowingly accepting, and what it costs your team. That's something you can defend.
Reaching 80% coverage of the vulnerabilities attackers actually exploit takes roughly 62% of your backlog with a rbvm tool and 50% with CVSS, but only 2% with Empirical. An RBVM-style tool can underperform due to scoring on a static snapshot of the past instead of anticipating what attackers will exploit next.
From prioritizing to defending
CVSS told us how bad a vuln could be. RBVM told us how likely it was to be used. The next step is being able to stand behind the line you drew, with data that shows what you covered, what you accepted, and why.
Because when the board asks, "Why the hell didn't we fix that vulnerability?", the best answer is one you can defend with data. Not an apology.
