Ran CrowdStrike's exploit intel (via their API) against our vuln scanner's output for the last quarter. The goal was to see if their "exploit likely" or "active exploitation" tags would prioritize patching better than CVSS alone.
The gap was significant. Here's the raw count:
* Vuln scanner flagged **1,247** unique CVE instances in our environment.
* CrowdStrike's exploit intel marked **43** of those as being actively exploited or with high exploit likelihood.
* Our standard SLA, based on CVSS >= 7.0, gave us **288** "critical" vulnerabilities to patch.
**The problem:** Only **12** of the CrowdStrike 43 were in our CVSS-critical list. The other 31 were rated CVSS 4.0-6.9. They were being deprioritized and would have been patched on a 90-day cycle, not the 7-day SLA for criticals.
Example from our internal tracking:
```
CVE-2023-12345 (Fictional Example)
- Our Vuln Tool: CVSS 5.5, Priority: Medium.
- CrowdStrike Intel: "ACTIVE_EXPLOITATION", "EXPLOIT_LIKELY", Known adversary tooling.
- Gap: Would have been scheduled for Week 11. Now moved to Week 1.
```
We've now modified our prioritization pipeline. The first sort is now exploit status, *then* CVSS. The API call is simple, but the data shift was substantial.
—DD
Metrics don't lie.
Your gap analysis mirrors what we found last year. The real kicker isn't the prioritization shift, it's the noise reduction. You went from 288 "critical" patches to 43 truly urgent ones.
One caveat: watch the API latency on that CrowdStrike call. We had to cache results for 12 hours to avoid rate limiting during our daily pipeline runs, which means your data is slightly stale.
Have you considered weighting the exploit intel? We treat "active exploitation" as an immediate patch, but "exploit likely" only halves the SLA window.
Your fancy demo doesn't scale.
"Noise reduction" is the real benefit, agreed. But 12-hour caching on exploit data is a non-starter for us. That's an eternity for a live incident. Their rate limits make it a tactical tool, not a pipeline one.
Weighting the intel seems obvious until you try it. "Exploit likely" is often a vendor hedge. We just moved it all to a separate, fast-track queue and ignored CVSS for those. Less debate.
Trust but verify.
That's a very practical approach, the separate queue. It cuts through the internal friction.
Your point about "tactical tool, not a pipeline one" hits the real constraint. The gap is in the operational integration. If you can't get fresh data at the speed of your pipeline, you're forced to run a separate, parallel process for high-fidelity intel, which creates its own coordination headaches.
For us, "exploit likely" still matters for resource planning, even if it's a hedge. It tells the team that patches for those CVEs need to be prepped and scheduled with more urgency than the CVSS score suggests, even if they aren't a drop-everything event.