Notifications
Clear all
Topic starter
20/08/2026 5:55 pm
TL;DR: Security teams are over-relying on CVSS and false-positive-prone triage, with only 12% of critical and high-severity vulnerabilities actually reachable in production and 73% of security time lost to manual triage, according to Pixee. The real shift is from severity-first workflows to exploitability-aware remediation that developers will accept.
NHIMG editorial — based on content published by Pixee: Agentic Security Engineering. The article argues that security teams are prioritising vulnerabilities wrong and should focus on exploitability-aware remediation
By the numbers:
- 92% of security teams use CVSS scores as their primary vulnerability prioritisation method.
- Only 12% of "Critical" and "High" severity vulnerabilities are actually reachable in production code.
- 73% of security teams report spending their time on manual vulnerability triage and only 27% on actual security improvements.
Questions worth separating out
A: Prioritise by combining exploitability, asset criticality, compensating controls, and process ownership.
Q: Why do vulnerability management programmes get stuck in backlog growth?
A: Because teams spend too much time validating findings that turn out not to matter, while real issues wait behind them.
Q: What do security teams get wrong about high CVSS scores?
A: They often treat CVSS as a complete ranking signal.
Practitioner guidance
- Implement reachability-based prioritisation Rank vulnerabilities by whether they are reachable in production, exposed through a real attack path, and connected to sensitive assets or identities before assigning engineering time.
- Reduce false positives before they enter triage Tune scanners and validation logic so that obvious non-issues are filtered out early, because backlog quality matters more than the raw number of findings.
- Measure remediation acceptance, not alert volume Track how many security fixes are merged, how quickly they are accepted, and how often recommendations are rejected or ignored by developers.
What's in the full report
Pixee's full analysis covers the operational detail this post intentionally leaves for the source:
- The report's per-study comparisons showing how different AppSec and software supply chain surveys converge on the same prioritisation problem.
- The data breakdown behind the 12% exploitability figure and how reachability analysis changes remediation queues.
- The operating-model examples for context-aware automation, including where developer workflows absorbed fixes more effectively.
- The fuller discussion of why AI-powered detection often increases work unless it is tied to remediation.
👉 Read Pixee's analysis of why security teams are prioritising vulnerabilities wrong →
Vulnerability prioritisation and remediation gaps: are controls keeping up?
Explore further
20/08/2026 6:35 pm
Exploitability, not severity, is now the real governance variable. Severity scores still have value for communication, but they break down as a prioritisation mechanism when reachability and runtime context are ignored. In identity-heavy environments, the same flaw can be harmless in one service and exploitable in another if privilege boundaries, tokens, or service paths differ. The practical conclusion is that vulnerability governance must align with actual access paths, not abstract scorecards.
A question worth separating out:
Q: How can organisations make remediation faster without adding more analysts?
A: They should move fixes closer to the developer workflow and automate context gathering so security teams spend less time translating findings. The goal is not more alerts but more accepted fixes. When remediation guidance is specific to the codebase and deployment pattern, teams can act faster with the staff they already have.
👉 Read our full editorial: Security teams are prioritizing vulnerabilities wrong
