Press TechRound interviews Secure.com CEO on the future of AI security
Read

Stop Patching By CVSS. Fix What Attackers Can Actually Use.

Learn why exploitability should decide your patch order, and how offense proves what defense should harden first.

TL;DR

Most teams sort their patch queue by CVSS score. That sorts it by how bad a flaw could be in theory, not by what attackers are actually using. So the queue fills with thousands of criticals while the few that matter sit somewhere in the pile. The better move is to invert the sort. Lead with what is proven exploitable and reachable in your environment, then rank inside that small set. Filtering this way can cut the urgent list by around 95 percent. And the strongest proof of what is exploitable does not come from a score. It comes from attacking your own defenses and seeing what breaks.

Introduction

The NVD adds more than 40,000 new CVEs a year, roughly 77 a day. No team can patch all of them. So the real question is not how many criticals you have. It is which handful an attacker could actually use against you today, and whether you can prove it.

Why CVSS is not a risk score

CVSS was never built to tell you what to fix first. It measures severity, how bad the damage would be if a flaw were exploited. It does not measure whether anyone is exploiting it, or whether an attacker can even reach the asset.

FIRST, the group that maintains CVSS, says this plainly. The base score measures severity, not risk. A queue sorted by CVSS is a queue sorted by hypothetical worst case.

The result is familiar. Scanners label thousands of findings critical. Research consistently shows only a small fraction of published CVEs are ever exploited in the wild, yet most carry high or critical scores. So teams drown in severe looking work that reduces very little real risk.

What exploitability actually means

Exploitability asks a different question. Not how bad could this be, but is anyone using it, and can they reach it here.

Three signals answer that better than severity alone:

  • Known exploitation. The CISA KEV catalog lists CVEs with confirmed real world abuse. It is binary. A flaw is either being exploited or it is not.
  • Likelihood. EPSS estimates the chance a flaw gets exploited in the next 30 days, updated daily. It flags what is trending toward attack before it hits KEV.
  • Reachability. A critical bug on an isolated internal box with no inbound route is not the same as the same bug on an internet facing service.

Invert the sort. Lead with known exploitation and reachability to decide what is urgent, then rank inside that set by impact. A medium severity, internet facing, actively exploited bug outranks a CVSS 9.8 sitting on an unreachable box. Teams that filter this way can shrink the urgent set by around 95 percent.

Even exploitability data has a blind spot

KEV and EPSS are global signals. They tell you what is being exploited across the internet. They do not tell you whether an attack would actually succeed against your specific controls, in your specific environment.

That is the missing layer. A flaw that is exploitable in the wild might be blocked by your firewall, your EDR, or your segmentation. Another might sail right through. A score cannot see that. Only testing can.

The strongest proof of exploitability is an attack

This is where offense earns its place. Instead of assuming a finding is exploitable, you attack your own environment inside an approved scope and watch what actually breaks. The paths that succeed are your real priorities. The ones your controls stop can wait.

At Secure.com this is what “powered by offense” means. The Red Teammate attacks a scoped environment and validates what is truly exploitable. That evidence sets the fix order. Defensive teammates then harden the proven paths first, and prove the fix worked with a retest.

The movement is simple: attack, harden, prove, repeat. Offense discovers what matters. Defense closes it. The teammate that attacks teaches the teammate that defends. Findings become action instead of another PDF backlog.

How Secure.com helps

Secure.com gives you governed AI security teammates where offense sets the priorities and defense acts on them, all inside limits your team controls.

  • The Red Teammate attacks an approved, scoped environment and validates what is really exploitable.
  • Exploitability evidence, not raw CVSS, sets what gets hardened first.
  • Defensive teammates harden the proven paths, then retest to prove the risk is gone.
  • Every attack, action, approval, and result is logged for a clean audit trail.
  • It sits above the stack you already own, so your scanners and controls stay in place.

The takeaway

A patch queue sorted by CVSS is sorted by fear, not risk. Lead with what is proven exploitable and reachable, and the list of things that actually matter gets short and clear. The most reliable way to know what is exploitable is to attack it and see. That is the whole point of letting offense drive defense.

FAQs

Is a CVSS score the same as risk?
No. CVSS measures severity, how bad a flaw would be if exploited. It does not measure whether anyone is exploiting it or whether an attacker can reach the asset. FIRST, which maintains CVSS, states the base score measures severity, not risk.
How should a SOC prioritize which vulnerabilities to fix first?
Lead with exploitability. Filter by known exploitation using the CISA KEV catalog and by likelihood using EPSS, factor in whether the asset is reachable, then rank that small set by impact. This inverts the usual CVSS-first sort.
What is exploitability based prioritization?
It is ranking vulnerabilities by whether attackers are actually using them and can reach them in your environment, rather than by theoretical severity. Known exploitation, likelihood, and reachability drive the order.
Can EPSS and KEV really cut the workload that much?
Research shows that combining CISA KEV and EPSS with severity can reduce the urgent remediation set by roughly 95 percent, because only a small fraction of CVEs are ever exploited.
How does offensive testing inform defense?
Offensive testing attacks your own environment in an approved scope to prove which flaws are actually exploitable against your live controls. Those proven paths set the fix order, so defense hardens what matters first instead of guessing from a score.