Patrick Garrity, Security Researcher at VulnCheck, has a data problem with how the industry prioritizes vulnerabilities, and the data is his own. After manually categorizing roughly 800 exploited vulnerabilities by technology type each year, what he keeps finding is that the CVSS severity distribution of exploited CVEs tracks closely with the overall CVE population. Meaning the scoring system most teams use to decide what gets patched first has no meaningful relationship to what threat actors are actually targeting. He hasn't yet sliced it fully by category, but what's already visible is enough to warrant rethinking your triage logic.

He also walks through VulnCheck's exploitation velocity data: roughly 29% of exploited CVEs already have exploitation evidence on or before the day the CVE is published. His read on that number is direct if you're in that bucket, you're likely already compromised before you've had a chance to prioritize the patch.

Topics discussed:

Why the CVSS severity distribution of exploited CVEs mirrors the overall CVE population
Exploitation velocity data: roughly 29% of exploited CVEs have evidence on or before CVE publish date
How MFA adoption shifted threat actor focus from credential compromise to direct exploitation
Tree map methodology for categorizing 800+ exploited vulnerabilities by technology type annually
Cascading vulnerability research: how one high-profile exploit draws threat actors and researchers to adjacent products
Source validation framework for assessing reliability across 118+ exploitation evidence reporters
Vendor security-through-obscurity blocking defenders from building detections
EU Cyber Resilience Act mandating 24-72 hour exploitation disclosure windows in 2026
How Coalition uses vendor risk indices to set cyber insurance rates based on technology stack

Key Takeaways:

If your remediation SLAs are gated on CVSS score, you're likely deprioritizing real exposure. Patrick's data shows the severity distribution of what gets exploited tracks the overall CVE population, not a cluster at the critical end.
For any CVE where exploitation evidence predates the publish date, treat it as a probable breach, not a patching event. Patrick's framing: you're "likely already compromised." IR engagement should precede remediation, not follow it.
When a major exploitation event lands on a product, immediately pull your full inventory for adjacent products in the same technology category. Both threat actors and researchers start looking at related products the moment a category gets attention.
Audit your network edge devices for end-of-support and end-of-life status. Many of these products carry 20-30 years of tech debt and were never built with product security as a baseline consideration.
When evaluating or renewing network security products, ask the vendor directly: what does your vulnerability disclosure process look like, and is patching automated? If remediation requires a manual change control window every time, that's a structural liability that compounds under pressure.
Push back on vendors who restrict patch details or technical indicators to paying customers. Threat actors who already reversed the product don't need that information. Defenders who are trying to build detections do.
Look at how insurance carriers like Coalition score your technology stack by vendor risk. If products you're running carry a high-risk rating in those indices, that's worth taking into a vendor conversation or a board briefing it's independent, data-backed validation that your exposure is real.

Listen to more episodes: