TL;DR: As AI-driven code analysis multiplies scanner output, 95 to 97 percent of reported vulnerabilities are never exploited in the wild, according to ArmorCode, so teams must prioritize by reachability, exploitation probability, and business context rather than severity alone. The practical shift is from chasing noise to defending the small slice of findings that can actually affect the business.
At a glance
What this is: ArmorCode argues that AI-scale vulnerability discovery is turning backlog volume into a triage problem, not a patching problem.
Why it matters: This matters because IAM, NHI, and broader security programmes cannot defend everything equally, so teams need a defensible way to separate exploitable risk from noise.
Context
Vulnerability management breaks down when teams treat every finding as equally actionable. As scanner volume rises, the real governance problem becomes deciding which issues are reachable, exploitable, and important to the business rather than simply which ones score highest on a generic severity scale. In practice, this shifts the control question from discovery to prioritization.
The article's identity angle is indirect but genuine: AI-accelerated code analysis can surface flaws across repositories, APIs, and services that sit behind authentication, privilege boundaries, and application ownership. That means remediation decisions increasingly intersect with access paths, exposed services, and business-service criticality rather than isolated technical defects.
Key questions
Q: What breaks when organisations still rely on severity-only vulnerability management?
A: They fix the wrong things first. Severity-only models miss whether an issue is reachable, already exploited, or likely to be automated by attackers, so limited effort gets spent on lower-value work while high-risk exposure persists. In fast-moving environments, that gap is enough to turn disclosure into compromise.
A: Treat CVSS as a baseline, then re-rank findings using exploit intelligence, asset criticality, and internet exposure. A moderate vulnerability on a high-value, reachable system can be more urgent than a critical score on a low-value isolated asset. The right order is driven by attacker likelihood and business impact, not score alone.
Q: How do you know if vulnerability triage automation is actually working?
A: Look for shorter time from discovery to assignment, fewer duplicate reviews, and a smaller backlog of stale findings. If automation is effective, analysts spend less time sorting inputs and more time resolving the issues that actually change risk.
A: It is both, but governance is the primary issue. Better tooling helps correlate and deduplicate findings, yet the real decision is how the organisation assigns risk, ownership, and remediation priority. Without that policy layer, more scanning only creates more noise and more confusion.
Technical breakdown
Why severity scores fail under AI-scale discovery
CVSS was built to describe technical impact, not operational likelihood. Under AI-scale scanning, that distinction matters because thousands of findings may be generated across assets that differ wildly in reachability, exposure, and business effect. A high score on a dead code path is not the same as a moderate score on an internet-facing service. The core architectural error is treating a vulnerability as self-contained when exploitability depends on environment, path, and compensating controls. In a noisy pipeline, static scoring alone becomes a sorting aid, not a risk control.
Practical implication: Use severity as an input, not the decision rule, when queueing remediation.
How reachability and exploit probability change triage
Reachability asks whether an attacker can actually get to the flaw from a meaningful attack path. Exploit probability asks whether the flaw is likely to be used in the near term. Together they separate theoretical exposure from actionable risk. EPSS-like probability signals and environment context help identify which issues deserve immediate engineering time, while unreachable or dormant findings can be tracked without consuming scarce response capacity. This is the practical core of risk-based triage: reduce the backlog by eliminating false urgency, not by lowering standards.
Practical implication: Build triage workflows that combine exploitability signals with exposure data before opening remediation work.
Why business context is the final decision layer
Two identical vulnerabilities can create very different outcomes depending on whether they sit on a public payment service, an internal staging system, or a low-value utility. Business context turns a vulnerability into an enterprise risk decision by accounting for asset criticality, data sensitivity, compensating controls, and owner responsibility. Without that layer, teams are still scoring defects; with it, they are judging impact. That is why prioritization cannot be delegated entirely to scanners or generic severity bands, especially when AI inflates the number of findings faster than teams can review them.
Practical implication: Attach each finding to an owned service, data class, and exposure profile before assigning remediation priority.
Threat narrative
Attacker objective: Exploit the narrow set of vulnerabilities that are both reachable and business-relevant before defenders can prioritize them.
- Entry occurs through AI-accelerated code generation and analysis that floods repositories, containers, and APIs with findings faster than teams can review them.
- Escalation happens when severity-first triage pushes truly reachable flaws behind large volumes of lower-value alerts.
- Impact follows when teams spend scarce engineering time on non-exploitable issues while exposed, reachable vulnerabilities remain open.
- Operationally, the attacker objective is to exploit the small subset of flaws that combine reachability, probability, and business value before defenders can separate them from noise.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Risk-based triage is now a governance control, not just a workflow choice. When vulnerability discovery scales faster than human review, severity-only queues stop being defensible. The decisive question becomes whether a flaw is reachable, exploitable, and connected to a business service that matters. Practitioners should treat prioritization as an operational risk filter, not an engineering convenience.
AI-scale finding growth exposes a control gap in how teams assign remediation attention. The article's central problem is not more vulnerabilities in the abstract, but more false urgency. That creates remediation drag, developer fatigue, and weaker credibility for security operations. Alert fatigue at AI scale: when every scanner output looks urgent, the programme loses the ability to distinguish signal from noise.
Business context is what turns a technical flaw into a security decision. Asset criticality, data sensitivity, internet exposure, and compensating controls are the variables that severity scores miss. In identity-heavy environments, the same logic applies to exposed services, tokens, and privileged pathways. Teams that cannot map findings to ownership and exposure are not doing risk management; they are doing backlog management.
KEV-style empirical evidence should outrank abstract score inflation. If a vulnerability is already being exploited in the wild, that fact should override most generic ranking debates. The article correctly treats observed exploitation as a forcing function, which aligns with NIST-CSF response planning and CIS Controls on vulnerability management. Practitioners should prioritise exploit evidence over theoretical severity wherever the two conflict.
What this signals
Vulnerability triage now behaves like a risk governance function. As AI increases the volume of findings, teams need a defensible method for deciding what deserves engineering time and what should remain in monitored backlog. The programme that wins here will be the one that can map findings to exposure, ownership, and business impact quickly.
AI-scale discovery creates an attention problem before it creates a patching problem. Security leaders should expect more pressure on triage queues, developer workflows, and release governance as scanners and code analysis tools generate larger backlogs. The practical response is not to chase every alert, but to make prioritisation measurable and repeatable.
For practitioners
- Implement reachability-based triage Combine exposure, authentication boundary, and code-path analysis before assigning remediation priority. Findings that cannot be reached or triggered in your environment should move to a lower review tier rather than consuming immediate fix capacity.
- Weight exploit evidence above raw severity Use exploit intelligence, including observed active exploitation, to override static severity when the two conflict. A vulnerability being used in the wild deserves faster attention than a higher-scoring flaw with no credible attack path.
- Attach findings to business services Map each vulnerability to the application, owner, environment, and sensitive data it can affect. That context is what makes prioritization defensible when multiple scanners and thousands of findings are in play.
- Separate backlog tracking from remediation queues Keep low-likelihood findings visible for audit and trend reporting, but do not let them block release decisions or displace exploitable issues from engineering queues.
Key takeaways
- AI-driven scanning is turning vulnerability management into a prioritisation problem because human teams cannot chase every new finding.
- Reachability, exploit probability, and business context separate meaningful exposure from low-value noise.
- Programmes that still rely on severity alone will keep burning effort on issues that do not change real-world risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 — Risk Assessment | The article is about deciding which vulnerabilities are truly risky in context. |
| Recommendation — Use risk assessment to rank vulnerabilities by exposure, exploitability, and business impact. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The core subject is prioritising remediation across a large vulnerability backlog. |
| Recommendation — Operationalise continuous vulnerability management so reachable flaws are remediated ahead of noise. | ||
| MITRE ATT&CK | TA0007;TA0010 — Discovery; Exfiltration | The article focuses on exploitable flaws that lead to real attack outcomes. |
| Recommendation — Map high-priority vulnerabilities to attacker discovery and exfiltration paths to guide hunting and response. | ||
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need a stronger operating model for identity risk across modern security programmes.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org