TL;DR: High-risk vulnerabilities increased 36% year over year, rising from 8.3% to 11.3% of all flaws found in Veracode's 2026 State of Software Security Report, as AI-assisted coding and expanding cloud-native attack surfaces push exploitable risk into code faster than traditional severity-led workflows can triage it. Severity alone is no longer a workable prioritisation model; exploitability-weighted remediation is becoming the control that matters most.
At a glance
What this is: Veracode says high-risk vulnerabilities, defined as flaws with both high severity and high exploitability, increased 36% year over year as exploitable risk outpaced traditional scanning-led triage.
Why it matters: This matters because application security teams, IAM leads, and cloud security teams need to prioritise real exploitability, not just severity labels, when scarce remediation capacity meets expanding attack surface.
By the numbers:
- High-risk vulnerabilities surged 36% year over year in Veracode's 2026 State of Software Security Report.
- Their share of all vulnerabilities rose from 8.3% to 11.3% in the report.
Context
High-risk application flaws are the ones that combine serious impact with practical exploitability, so they demand more than a severity-only queue. When development pipelines move faster and cloud-native systems expose more pathways, the real governance problem becomes deciding which flaws can turn into incidents, not just which ones look severe on paper.
The article frames two forces behind that shift: AI-assisted coding and a wider application attack surface built from microservices, APIs, and cloud-native services. For application security, that creates a prioritisation problem that overlaps with identity governance where APIs, service accounts, and access paths expand the blast radius of exploitable code.
The core message is typical of modern software portfolios rather than an edge case. As more flaws become both dangerous and reachable, teams need exploitability-weighted decisioning as a routine control, not an exception process.
Key questions
Q: What breaks when security teams rely on vulnerability severity instead of exploitability?
A: Prioritisation breaks first. Severity tells you how bad a flaw could be in theory, but exploitability tells you whether an attacker can actually use it in your environment. Without that distinction, teams overreact to noisy disclosures, miss reachable attack paths, and spend remediation capacity on issues that are urgent in name only.
Q: Why do AI-assisted development pipelines increase the need for stronger security review?
A: AI-assisted development can accelerate code production faster than traditional review and testing processes can absorb. That creates more chances for logic bugs, insecure patterns, and vulnerable dependencies to reach production. Security teams need controls that keep pace with release velocity, especially where findings must be prioritised by exploitability rather than volume 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.
Q: What should organisations do when cloud-native architecture expands the attack surface?
A: They should focus first on the services, APIs, and credentials that create the shortest path from flaw to impact. In distributed systems, the right question is not how many vulnerabilities exist, but which ones can be reached through a live trust path that an attacker can actually use.
Technical breakdown
Why exploitability changes vulnerability prioritisation
Severity measures the maximum plausible impact of a flaw, while exploitability measures how realistically an attacker can use it. Those are different governance questions. A high-severity bug that is hard to trigger may sit for a while, but a moderately severe bug that is trivial to weaponise can produce immediate loss. Traditional scoring often flattens those differences into backlog noise. Risk-based prioritisation restores the distinction by combining impact, exposure, and threat intelligence into one decision path.
Practical implication: rank remediation by exploitability and exposure, not by severity labels alone.
How AI-assisted coding changes application risk
AI-assisted coding can accelerate delivery, but it also increases the rate at which flawed patterns enter codebases. The problem is not that AI writes every bad line, but that speed compresses review time and can normalise insecure constructs before they are caught. In application security terms, this raises the rate of issues that scanners will flag as high severity, while leaving teams with less time to distinguish theoretical defects from actively exploitable ones.
Practical implication: add validation and review gates where AI-generated code enters the pipeline.
Why microservices and APIs amplify the attack surface
Microservices break applications into many small services, and API-heavy designs multiply the trust relationships between them. That creates more entry points, more failure modes, and more places where weak authorisation or exposed functionality can be abused. The identity angle is real here: every service account, token, and API credential extends the practical reach of a flaw. In a distributed system, exploitability often grows because the attacker only needs one reachable path into a larger trust chain.
Practical implication: map the most exposed services and credentials before deciding which flaws to fix first.
Threat narrative
Attacker objective: The attacker wants a flaw that is both reachable and damaging enough to convert quickly into operational disruption or data compromise.
- Entry occurs through an exposed application flaw that is both severe and easy to exploit in a modern codebase or API path.
- Escalation follows when the flaw reaches a service, microservice, or cloud-native trust boundary with broader access than intended.
- Impact lands as data exposure, service compromise, or lateral abuse that is easier to achieve because the vulnerable path was prioritised too late.
Breaches seen in the wild
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
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
Exploitability, not severity, is becoming the real triage primitive: teams that still sort queues by criticality alone are optimising for the wrong signal. High-severity defects can be noisy, but exploitability tells you what can become an incident under current exposure conditions. The practical conclusion is simple: security backlogs need a live risk lens, not a static scoring list.
AI-assisted development raises governance debt faster than most application security programmes can absorb: the issue is not only defect volume, but the compression of review and validation time. That means governance controls have to move closer to code creation and pipeline validation, where exploitable patterns are introduced. Practitioners should treat AI code output as a throughput problem with security consequences, not just a productivity feature.
Attack surface sprawl: microservices, APIs, and cloud-native dependencies create more chances for a flaw to become reachable. That matters because reachability turns technical weakness into operational risk, and the identity bridge is direct when service accounts, tokens, and delegated API access expand the blast radius. Teams need to govern paths to impact, not just inventory flaws.
Exploitability-weighted remediation is now a programme design requirement: the security function has to decide what to fix first based on exposure, likelihood, and business reach. That changes reporting, resourcing, and developer conversation patterns. The practical conclusion is to treat prioritisation itself as a security control.
What this signals
Exploitability-weighted prioritisation: the article shows why modern application security has to rank flaws by reachability and business impact, not just by severity scores. That is the control shift practitioners need when code volume and cloud complexity outpace manual triage.
AI-assisted coding changes the economics of review. Security teams should expect more defects to enter faster, which means the pipeline needs stronger validation at the point of introduction rather than only at the point of detection.
For practitioners
- Adopt exploitability-weighted triage Build remediation queues around exploitability, exposure, and impact instead of CVSS severity alone, so urgent flaws surface ahead of theoretical ones.
- Insert validation gates for AI-generated code Require review, testing, and security checks where AI-assisted code enters the pipeline, especially for patterns that repeatedly produce high-severity flaws.
- Map reachable attack paths first Identify the APIs, microservices, and cloud-native trust boundaries that make a defect realistically exploitable before assigning remediation priority.
- Tie security backlog decisions to business exposure Use threat intelligence and asset criticality to explain why one flaw should move ahead of another, so remediation capacity tracks actual risk reduction.
Key takeaways
- High-risk vulnerabilities are becoming more concentrated, which makes backlog management a governance problem as much as a technical one.
- The report's 36% increase and the move from 8.3% to 11.3% show why severity-only scoring misses the flaws most likely to matter.
- Exploitability-weighted remediation gives teams a better way to spend limited effort on the issues most likely to become incidents.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article is fundamentally about prioritising vulnerability remediation based on real risk. |
| Recommendation — Use CIS-7 to drive remediation of vulnerabilities that are both reachable and likely to be exploited. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | The post centres on identifying and prioritising exploitable weaknesses across applications. |
| Recommendation — Document exploitable weaknesses and tie them to risk-based remediation workflows under ID.RA-01. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | The article highlights API proliferation as part of the expanded attack surface. |
| Recommendation — Review exposed APIs for authorization failures that make flaws immediately reachable to attackers. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The article contrasts simple scanning with exploitability-weighted prioritisation. |
| Recommendation — Pair RA-5 scanning with exploitability data so remediation targets the flaws most likely to be abused. | ||
| MITRE ATT&CK | TA0001;TA0006 — Initial Access; Credential Access | The attack pattern depends on flaws that give attackers an easy entry and a path to abuse. |
| Recommendation — Map exploitable application weaknesses to Initial Access and Credential Access to improve threat-driven triage. | ||
Key terms
- High-Risk Vulnerability: A high-risk vulnerability is a flaw that combines serious potential impact with a practical path to exploitation. The key distinction is not just whether the issue exists, but whether an attacker can realistically use it to gain access, disrupt services, or move deeper into an environment.
- Exploit-Weighted Prioritisation: Exploit-weighted prioritisation is the practice of ranking remediation work by whether a vulnerability is actively exploited, not just by technical severity. It combines external threat signals, fix availability, and asset exposure so teams can reduce real attacker opportunity first.
- Attack Surface Expansion: Attack surface expansion is the growth in the number of reachable entry points, trust relationships, and exposed services that attackers can target. In modern applications, APIs, microservices, cloud services, and connected identities all add places where a vulnerability can become operationally important.
- Application security backlog: An application security backlog is the queue of defects, misconfigurations, and weaknesses waiting for remediation. It becomes a governance problem when the queue is sorted by score alone instead of by likely exploitability and business exposure.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, machine identity security, IAM, and secrets management through the industry's only accredited NHI security programme. It helps security and identity practitioners connect access control discipline to broader risk reduction across modern environments.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org