Vulnerability Prioritization is Not Just About Severity, But Exploitability in Context
Published
Question: CISA is urging organizations to prioritize vulnerabilities based on real-world risk rather than severity scores alone. What factors best indicate whether a vulnerability is likely to be exploited? What vulnerability prioritization approaches are effective for different industries and environments?
Mike Wood, CMO at Rapidfort
Attackers are now equipped to exploit security vulnerabilities much faster than organizations are able to defend against attacks. The latest CISA shift from “patch everything” is another recognition of this reality. Severity scores are important, but they are no longer a true proxy of how bad a vulnerability really is.
The issue is now can an adversary take advantage of this vulnerability against a particular system in a specific environment quickly enough to gain a return. There are now several practical versus theoretical factors to consider with respect to the likelihood of an exploit.
This includes
- Reachability of the target via the Internet or an untrusted network,
- Whether the CVE is in CISA’s KEV catalog, and
- Is there available exploit code that is reliable and automatable.
Another critical factor is whether the attacker is able to:
- Gain meaningful control
- Credential access, data access, or
- A way to move laterally
All of this is important, but if the exploit is simply showing up in a scan result, but the vulnerable component is not actually in a production environment, it isn’t an actual threat vector.
Many programs still fall short because they assume that every discovered component represents a live risk until someone proves otherwise. This approach creates continuous backlogs, slows authorization cycles, and populates remediation queues with software the application may never execute.
The result is an imbalance between discovery and execution as organizations have become very good at finding vulnerabilities and much less capable of removing, mitigating, or accepting them in an intelligent manner.
Each environment typically requires different prioritization approaches.
- A federal agency or financial institution would place heavy weight on
- internet exposure,
- exploited status,
- identity impact, and
- mission-critical systems.
- A hospital or healthcare provider must factor in patient safety and uptime, meaning patching a clinical system without testing could create more immediate harm than the vulnerability itself.
- It makes sense that Industrial and OT environments prioritize
- exploitability,
- segmentation failure, and
- compensating controls since downtime and safety risk are critical.
- Cloud- native and software supply chain environments will need to focus on
- curated code,
- file execution,
- secrets, and
- build pipeline integrity.
Given all of this, one of the most important considerations is that the timeline is changing dramatically.
Federal mitigation cycles are usually counted in weeks, but the exploit windows are collapsing to hours. AI widens the gap, and attackers are able to take advantage of automation for vulnerability disclosure, exploit generation, scanning, and targeting.
Defenders are still saddled with:
- Change boards
- Maintenance windows
- Older systems, and
- Ownership silos.
Improving vulnerability scoring isn’t the immediate solution; organizations and businesses must reduce the attack surface and what they have to score.
Spending a little more time to scrutinize and question:
- Why specific software, images, and packages are present
- Remove unused software images, shells, services, editors, and operating system components before deploying software in production.
- Embracing minimization at the procurement and engineering stages and not just remediation workflows.
- Risk-based prioritization is necessary, but it is not sufficient.
- Triage helps organizations spend scarce remediation capacity wisely, but does not reduce the volume of inherited exposure.
The most effective approach will both fix the vulnerabilities most likely to be exploited now and systematically remove the unnecessary software that would otherwise become tomorrow’s emergency.
The easiest vulnerability to fix is still the one that was never there.
Related
