High-risk vulnerabilities are rising as exploitability outpaces scanning

At a glance

What this is: Veracode reports a 36% year-over-year rise in high-risk vulnerabilities, with exploitable flaws increasing from 8.3% to 11.3% of all findings.

Why it matters: Security and IAM teams should care because exploitability-driven risk expands the blast radius across applications, APIs, cloud services, and the identities that secure them, making prioritisation more important than raw vulnerability counts.

By the numbers:

• 36% year-over-year.
• The proportion of these flaws grew from 8.3% to 11.3% of all vulnerabilities found.

👉 Read Veracode's analysis of the 36% rise in high-risk vulnerabilities

Context

High-risk vulnerabilities matter because they combine severity with exploitability, which is the point at which a flaw becomes operationally dangerous rather than merely theoretically bad. In modern application estates, especially cloud-native and API-heavy environments, teams can no longer assume that all critical findings deserve equal treatment. Application security programmes now need a risk lens that separates exploitable exposure from backlog noise.

The identity connection is indirect but real. APIs, service accounts, tokens, and other non-human identities often sit behind the application paths where exploitable flaws are reached and abused, so application risk and credential governance increasingly overlap. When development velocity rises through AI-assisted coding, the governance problem is not only code quality but also the trust boundary around the identities and secrets that code depends on.

Key questions

Q: How should security teams prioritise vulnerabilities when exploit timelines are shrinking?

A: Prioritisation should combine exploitability, reachability, internet exposure, identity proximity, and business criticality. A medium-severity issue on a sensitive, reachable system may outrank a critical issue in an isolated environment. The goal is to reduce the exposure window on the paths attackers can actually use, not to clear the longest backlog.

Q: Why do AI-assisted coding tools complicate security assurance for enterprise software?

A: They increase code output faster than teams can prove the output is safe. Security assurance is slower because it depends on review, testing, and validation of behaviour, especially where access and trust are encoded in the application. The gap widens when organisations treat generation speed as the same thing as control maturity.

Q: What do security teams get wrong about vulnerability management in complex environments?

A: They often treat the software flaw as the whole problem. In practice, the risk also depends on deployment topology, third-party dependencies, privileged identities and how quickly the environment can absorb a fix without disruption. Effective vulnerability management is therefore a coordination problem across architecture, operations and identity governance.

Q: When should organisations re-evaluate vulnerability prioritisation models?

A: Organisations should re-evaluate prioritisation whenever application complexity, API sprawl, or AI-assisted development increases faster than their remediation capacity. Those conditions create more exploitable exposure and make static scoring less useful. A newer model should account for attack path, asset criticality, and the identities that can reach the weakness.

Technical breakdown

Why exploitability changes vulnerability priority

Severity measures potential impact, while exploitability measures how likely an attacker can turn a flaw into access or disruption. A high-severity issue that is hard to reach may never be used, but a moderately severe issue with easy exploit paths can become the real entry point. That is why raw CVSS ranking often fails in modern environments. The practical challenge is to combine vulnerability metadata with threat intelligence, asset context, and attack path likelihood so remediation reflects real adversary behaviour rather than abstract score ordering.

Practical implication: prioritise remediation by exploitability and asset exposure, not by severity score alone.

How AI-assisted coding increases application risk

AI coding assistants accelerate software production, but they also amplify the volume of insecure patterns entering repositories, libraries, and pipelines. The issue is not that AI creates a new class of vulnerability, but that it can scale the introduction of familiar flaws faster than review and validation processes adapt. In practice, this pushes more issues into the software supply chain earlier in the lifecycle, which means scanning alone is not enough. Teams need stronger code review gates, dependency validation, and policy checks before code reaches production.

Practical implication: add pre-merge validation and policy controls for AI-generated code before it reaches shared branches.

Why cloud-native and API sprawl magnify blast radius

Microservices, third-party APIs, and cloud-native deployment patterns expand the number of trust relationships an application must manage. Each service boundary, API integration, and secret creates another place where an exploitable flaw can be reached, chained, or reused. This turns vulnerability management into an exposure management problem, because the same defect can have very different consequences depending on where it sits in the architecture. The practical question is no longer just whether a flaw exists, but whether it can be reached from an identity, a service, or a public interface that matters.

Practical implication: map vulnerabilities to reachable services, exposed APIs, and the identities that can invoke them.

NHI Mgmt Group analysis

Exploitability is now the deciding variable in application risk. High-severity findings only become operationally meaningful when an attacker can actually use them. That shifts programme design away from simple count-based backlogs and toward exposure-aware triage, where the reachable flaw outranks the alarming but inert one. For application security leaders, the implication is that prioritisation quality is now a core control, not just a workflow preference.

AI-assisted development is accelerating vulnerability intake faster than governance catches up. The article's central risk is not novel attack logic, but the speed at which familiar weaknesses are entering code. That creates governance debt across engineering, security, and release management, because validation must now occur earlier and more continuously. The practical conclusion is that code-generation speed must be matched by control-speed.

API sprawl and cloud-native design are turning software risk into identity-reachable risk. In modern environments, exploitable application flaws often sit adjacent to service accounts, tokens, and workload credentials that enable downstream abuse. That makes application security and NHI governance part of the same exposure chain, even when teams run them as separate programmes. Identity-reachable exposure: a flaw becomes materially more dangerous when an authenticated service or non-human identity can reach it directly. Practitioners should assess reachability before they assess remediability.

Severity-led prioritisation is creating remediation blindness. When every critical issue looks equally urgent, teams spread effort too thin and leave the most exploitable defects sitting in the backlog. This is a governance failure as much as a technical one, because it obscures decision quality and makes risk reduction harder to measure. For practitioners, the real question is whether remediation time is aligned to exploitability, not whether tickets are being closed.

What this signals

Exploitability-led prioritisation is becoming a governance signal for programmes that span application security and identity control. When flaws are reachable through service accounts, API keys, or workload tokens, remediation decisions need to reflect the identity path as much as the code defect. That is where identity-reachable exposure becomes a useful operating concept for security leaders.

The operational lesson for practitioners is to stop treating vulnerability management as a standalone scanning function. It now has to sit alongside secret management, workload identity governance, and release gating, because the attack surface is being shaped by both software design and machine access. For teams using external guidance, the NIST Cybersecurity Framework 2.0 remains a sensible structure for aligning protect, detect, respond, and recover work to the places where exploitable risk actually lives.

As AI-assisted development scales, the question shifts from whether more flaws will appear to whether organisations can absorb them without losing prioritisation discipline. Programmes that can correlate vulnerability severity with runtime reachability, owner context, and identity exposure will reduce risk faster than teams still relying on static queues. That capability will increasingly distinguish mature security operations from high-volume but low-impact remediation.

For practitioners

• Move to exploitability-weighted triage Rank vulnerabilities by exploitability, business reach, and exposure path before you assign engineering effort. Use threat intelligence and asset criticality to separate exploitable defects from theoretical ones.
• Gate AI-generated code before merge Add policy checks, secure code review, and dependency validation to the pull-request path so AI-assisted code cannot bypass human control points.
• Map vulnerable services to reachable identities Track which APIs, microservices, service accounts, and tokens can reach each high-risk flaw so remediation targets the paths an attacker would actually use.
• Reduce backlog noise in vulnerability workflows Separate severity reporting from remediation queues so teams can focus on high-severity, high-exploitability issues first and avoid treating every critical finding as equal.

Key takeaways

• High-risk vulnerabilities are increasing because exploitability is outpacing traditional severity-led triage.
• AI-assisted coding and cloud-native sprawl are expanding the number of reachable weaknesses that attackers can turn into access.
• Practitioners need exploitability-weighted prioritisation that links code flaws to the identities, APIs, and services that can actually reach them.

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.
• Identity-Reachable Exposure: Identity-reachable exposure describes a vulnerability or control weakness that can be accessed through a real identity path, such as a service account, API key, token, or workload credential. It is a useful way to connect application risk to the identities that can actually trigger or abuse it.

What's in the full report

Veracode's full report covers the operational detail this post intentionally leaves for the source:

• The underlying methodology behind the 36% year-over-year increase in high-risk vulnerabilities, including how severity and exploitability were combined.
• More detail on how AI-assisted coding affected the vulnerability profile across the software estate.
• The report's guidance on how application security teams can shift backlog triage into a risk-based remediation workflow.
• Portfolio-level context on where high-risk flaws are concentrating across modern application architectures.

👉 Veracode's full post covers the exploitability data, application drivers, and prioritisation implications in more detail.

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 helps practitioners connect identity controls to the broader security programme they already run.