Key Takeaways
- A Critical CVSS score does not mean a vulnerability is being attacked. Most never are.
- CISA KEV and EPSS add real exploitation evidence and probability on top of CVSS, so teams stop guessing.
- Nearly half of actively exploited vulnerabilities tracked by CISA KEV are old, pre-2021 bugs, not the newest CVEs.
- A threat-informed workflow combines exploit evidence, asset criticality, and business context before anything gets a patch ticket.
- Secure.com’s Cloud Security AI Teammate runs this prioritization work continuously, so your team spends time fixing instead of sorting spreadsheets.
A scanner flags 400 vulnerabilities on a Tuesday morning. Twelve are marked Critical. Your team has time to patch maybe 20 this week. Which ones do you pick? If the answer is “the ones scored highest,” you are probably about to spend your week on bugs nobody is trying to break into.
Why CVSS Alone Can’t Tell You What to Fix First
CVSS was built to measure how bad a flaw could be, not how likely someone is to use it. Those are two different questions, and security teams have been answering the wrong one for years.
Research from Mondoo’s 2026 State of Vulnerabilities report found that only 2.3% of vulnerabilities scored 7 or higher on CVSS were actually observed being exploited in the wild. Read that again. Nearly all the “urgent” work on a typical patch list never gets touched by an attacker.
Vulnerability risk scoring vs threat intelligence-led prioritization
Risk scoring on its own asks: how severe could this be if exploited? Threat intelligence-led prioritization asks a sharper question: is this being exploited, right now, against systems like mine? A framework that leans on both gets you closer to reality. One without the other leaves gaps. CVSS alone misses context. Threat intel alone misses coverage, since not every exploited bug makes headlines.
Why do security teams spend time on non-exploitable vulnerabilities
Two reasons, mostly. First, CVSS is the default column every scanner sorts by, so it becomes the default priority list by accident. Second, exploitability data used to be scattered across advisories, Twitter threads, and vendor blogs, so pulling it into a workflow took manual effort most teams didn’t have. The result: patch cycles built around theoretical severity instead of confirmed attacker behavior.
How does exploitability affect vulnerability prioritization
Exploitability should sit above severity in the decision, not beside it. A Medium-severity bug with a public proof-of-concept and active scanning against it is a bigger problem this week than a Critical bug sitting in unused code. Exploitability answers “can someone actually use this against me right now,” and that question should move a finding up or down the queue faster than a CVSS number ever could.
How does vulnerability management integrate with threat intelligence platforms
Vulnerability management and threat intelligence work best as one pipeline, not two separate tools that never talk. Threat intel feeds tell you which CVEs have proof-of-concept code, which ones are being scanned for on the open internet, and which are tied to active ransomware campaigns. That data gets matched against your asset inventory, so a CVE only becomes urgent if it actually touches something you run.
How does vulnerability management connect to CISA KEV for prioritization
CISA’s Known Exploited Vulnerabilities catalog is the clearest signal you’ll get. It only lists CVEs where CISA has confirmed real attackers used them, not vulnerabilities that could theoretically be exploited. As CISA puts it, the catalog exists to send a clear message to organizations to focus remediation on the vulnerabilities causing immediate harm based on adversary activity. That’s a short list compared to the full CVE database, and it’s the one most worth checking first every single day.
How does lack of threat intelligence reduce vulnerability prioritization accuracy
Skip threat intel and you’re left sorting by severity alone, which research keeps showing is a weak predictor of what gets attacked. Poor threat intelligence integration doesn’t just slow a VM program down. It actively points effort at the wrong targets, since a scanner has no way to tell you a Medium finding is being actively weaponized this week. Teams without this layer end up patching in the order a spreadsheet sorted them, not the order attackers care about.
One more number worth sitting with: CISA KEV data shows roughly 46% of actively exploited vulnerabilities date back to before 2021. These aren’t new zero-days. They’re old bugs still sitting unpatched on forgotten servers, still getting picked off because nobody thought to look backward.
Building a Threat-Informed Vulnerability Prioritization Workflow
A workflow that actually reflects risk needs four layers working together: what’s exploitable, what’s exploited, what matters to your business, and what’s actually reachable by an attacker.
- Start with asset criticality. A vulnerability on a public-facing login page matters more than the same bug on an internal test server nobody uses.
- Layer in CVSS as a baseline, not the final word. It tells you technical severity, and that’s still useful context.
- Add EPSS scores to estimate the probability a CVE gets exploited in the next 30 days, since this catches bugs that aren’t in KEV yet but are trending that way.
- Check CISA KEV last, weighted heaviest. Anything on that list, on an internet-facing or high-value asset, jumps the queue.
- Confirm exposure, meaning the vulnerable service is actually reachable, not buried behind five layers of network controls.
How to use CISA KEV to prioritize vulnerability remediation
Treat KEV as a floor, not a suggestion. If a CVE shows up on the CISA KEV catalog and it exists somewhere in your environment, that finding should move to the front of the line automatically, no debate needed. Pulling from the CISA KEV catalog for vulnerability risk prioritization works best when it’s checked daily, since CISA adds new entries as soon as exploitation is confirmed, sometimes just days after a CVE is published.
How to integrate threat intelligence into vulnerability prioritization
The mechanics are simpler than they sound:
- Pull your full vulnerability list from your scanner.
- Cross-reference every CVE against CISA KEV and EPSS in real time.
- Match the surviving high-risk list against your asset inventory for criticality and exposure.
- Route the top tier straight into a ticket, with the evidence attached, so engineering isn’t asking “why this one.”
- Repeat daily. Threat intelligence goes stale fast, so a monthly review misses the exploitation that happened three weeks ago.
Teams building this by hand usually stitch together a scanner export, a KEV CSV, and an EPSS API call in a spreadsheet. It works, until the CVE count triples and nobody has time to run the join every morning.
Where Secure.com’s Cloud Security AI Teammate Fits In
This is exactly the grind Secure.com built the Cloud Security AI Teammate to remove. Instead of your team manually cross-referencing CVSS, EPSS, and CISA KEV against a spreadsheet of assets every morning, the teammate does that correlation continuously, inside the scope and approvals your team sets. That’s the governed part. It doesn’t patch things on its own authority. It surfaces the evidence, ranks the real risk, and hands your team a queue that’s already sorted by what attackers are actually doing, not by a CVSS number sitting in a vacuum.
It also connects to the offense side of the loop. A Red AI Teammate can confirm which exposed vulnerabilities are truly reachable in your environment, and that validated evidence feeds straight into what the Cloud Security AI Teammate prioritizes for hardening next. The teammate that attacks teaches the teammate that defends.
Governed Defense, Powered by Offense. No More Grunt Work. No More Burnout. That’s the whole point of running attack, harden, prove, and repeat as one continuous loop instead of four disconnected steps.
If your team is still triaging by severity score alone, a single Cloud Security AI Teammate is enough to start closing that gap. It doesn’t require rolling out an entire platform to get value on day one.
FAQs
What percentage of vulnerabilities are actively exploited in the wild?
How does threat intelligence improve vulnerability prioritization?
What’s the difference between CVSS, EPSS, and CISA KEV?
Do you need both EPSS and CISA KEV, or is one enough?
The Bottom Line
Patch lists sorted by CVSS alone waste time on bugs nobody is trying to exploit while the ones actively used sit further down the queue. A threat-informed approach, CVSS plus EPSS plus CISA KEV plus real asset context, gets your team fixing the right things first. For a deeper look at how EPSS scores translate into an actual remediation workflow, see EPSS in Practice: A Real Vulnerability Prioritization Workflow. And if the next step is figuring out what to triage first when everything on the list looks urgent, The Exposure Prioritization Playbook walks through exactly that.
