Topic starter
11/11/2026 5:59 pm
TL;DR: Vulnerability backlogs grow when teams rank findings by severity alone, according to Plerion, because many critical CVEs are not exploitable in the environment that actually runs them. Practitioners need exploitability evidence to separate real exposure from inventory noise and focus remediation where it changes risk.
Editorial analysis by NHI Mgmt Group, based on content published by Plerion: “Your vulnerability backlog is mostly fiction”.
Key questions
Q: Why do vulnerability backlogs keep growing even when teams work harder?
A: Backlogs grow because modern applications generate far more findings than humans can triage well, especially when multiple tools report the same issue.
A: CVSS estimates how severe a vulnerability could be if exploited, while exploitability-based prioritisation focuses on whether exploitation is likely in practice.
Q: How do teams know if a vulnerability is truly exploitable?
A: They validate it in the live environment using safe testing that shows whether an attacker can reach the condition, trigger it, and move beyond it.
Practitioner guidance
- Gate remediation on exploitability evidence Require each high-priority finding to show the runtime conditions that make exploitation possible before it enters the urgent queue.
- Separate non-exploitable, uncertain, and exploitable findings Use distinct states for findings that are disproven, unresolved, or likely exploitable so engineers know what needs action now versus investigation later.
- Record the preconditions behind every deferral Store the OS, service state, network reachability, hardware, or feature requirement that makes a finding safe to deprioritise.
Bottom line: Vulnerability backlogs grow when teams measure abundance of findings instead of actual exploitable exposure.
Glossary terms: Exploitability, Operational Severity, Continuous Vulnerability Management, Runtime Context
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:06 pm
Exploitability is the governance boundary that vulnerability management has ignored. Presence-based scoring treats every CVE as if it were equally reachable, but operational risk only exists when the environment satisfies the exploit preconditions. That means backlog size is often a poor proxy for exposure, and triage has to shift from counting findings to proving reachability. The practitioner conclusion is simple: prioritise the flaws that can actually be used, not the ones that merely exist in a database.
A question worth separating out:
Q: What should security teams do first when every vulnerability is marked critical?
A: Start with exploitability and exposure, not score bands. Cross-reference the backlog against known exploited vulnerabilities, public proof-of-concept availability, and internet exposure, then attach asset ownership and business criticality. That quickly isolates the small subset most likely to become incidents and prevents remediation capacity from being spent on theoretical risk.
👉 Read our full editorial: Exploitability cuts through vulnerability backlog noise and risk scoring