A vulnerability backlog of several thousand findings isn't unusual. Neither is the observation that a large share of it is scored critical or high. CVSS describes how bad a vulnerability could be under ideal conditions for an attacker. It was never intended as a work queue.
What actually predicts exploitation
| Signal | What it tells you |
|---|---|
| KEV membership | This is being exploited right now, in the wild, confirmed. |
| EPSS probability | The modelled likelihood of exploitation in the next 30 days. |
| Reachability | Whether an attacker can get to the vulnerable component at all. |
| Asset criticality | What it costs you if this specific host is compromised. |
None of these are in the CVSS base score. A CVSS 9.8 on an internal host with no network path is a lower priority than a CVSS 7.5 that appears in the KEV catalogue and sits on an internet-facing service. Any ranking that can't express that is going to send your team to the wrong work.
Ranking is only half of it
Better ranking gets you a better list. It doesn't get you a smaller list. Closing exposure at volume needs the remediation to be produced, not described. A ticket that says upgrade OpenSSL is a request for someone else to do the engineering.
The output of vulnerability management should be an executed change, not a well-prioritised ticket.
Reversibility is the adoption gate
Teams will accept automated remediation exactly as far as they trust the rollback. Recording the rollback path before the change runs, and verifying the outcome after it, is what moves a remediation class from requires-approval to pre-approved. That transition is where the throughput actually comes from.