Notifications
Clear all
Topic starter
02/08/2026 12:25 pm
TL;DR: Vulnerability management backlogs become operational risk when teams treat CVSS as the primary triage signal instead of exploitability, PoC availability, and asset context, according to Nucleus. The practical shift is toward exposure-based prioritisation, where attackers and business criticality determine urgency, not scan volume.
NHIMG editorial — based on content published by Nucleus: From Noise to Urgency: Why Exploitability Matters
By the numbers:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
Questions worth separating out
Q: How should security teams prioritise vulnerabilities when proof of concept code is public?
A: Treat public proof of concept code as an escalation signal, not a technical footnote.
Q: What breaks when organisations rely on CVSS alone for remediation decisions?
A: CVSS alone creates a backlog of scores, not a backlog of risk.
Q: What breaks when vulnerability management is based only on CVSS scores?
A: CVSS-only prioritisation breaks when several lower-scoring flaws can be combined into a complete exploit path.
Practitioner guidance
- Prioritise on exploitability signals first Build a triage queue that weights proof of concept availability, active exploitation, internet exposure, and asset criticality ahead of raw CVSS score.
- Add identity and privilege context to every high-risk finding Tag findings that affect systems holding secrets, federation services, admin tooling, or workload access paths.
- Create a PoC-triggered escalation path When working exploit code appears, move the finding out of the normal backlog and into an accelerated workflow with owners, mitigations, and verification deadlines.
What's in the full article
Nucleus's full article covers the operational detail this post intentionally leaves for the source:
- How the webinar frames proof of concept code as the trigger for reprioritising vulnerability backlogs
- The specific way Nucleus positions EPSS alongside CVSS for day-to-day triage decisions
- Examples of how exploitability and asset criticality are combined in the prioritisation workflow
- The vendor's description of how its workflow surfaces the riskiest issues before patch teams reach them
👉 Read Nucleus's analysis of why exploitability matters more than raw vulnerability scores →
Exploitability over CVSS: what should vulnerability teams do first?
Explore further
02/08/2026 1:24 pm
Exploitability is the control variable that vulnerability management still treats as optional. CVSS gives teams a language for severity, but it does not answer the real operational question: can an attacker use this weakness now. When proof of concept code appears, the issue stops being theoretical and becomes a scheduling problem for the defender. The mature posture is to prioritise by weaponisation, reachability, and business impact, not by scanner noise alone.
A question worth separating out:
Q: Who should own exploitability decisions when a vulnerability affects privileged systems?
A: Vulnerability management should not own the decision alone when the flaw touches identity brokers, secret stores, admin tooling, or workload access paths. Ownership should include system operators, IAM or PAM leads, and security engineering so the response covers privilege reduction, containment, and verification. That keeps remediation aligned to actual blast radius.
👉 Read our full editorial: Exploitability is the real priority in vulnerability management
