GenAI code security is a scale problem, not a syntax problem

At a glance

What this is: Veracode’s 2026 GenAI Code Security Report says AI is writing more production code, but secure output is not improving fast enough to match adoption.

Why it matters: AppSec and software governance teams need to treat GenAI code security as a scale and verification problem, not a syntax problem, because vulnerable output can now expand faster than review capacity.

By the numbers:

• The 2026 GenAI Code Security Report found that roughly 44% of AI code generation tasks introduced a risky security vulnerability in tests.
• The average security pass rate across models is 56%, barely changed from 55% in the first report.
• GPT-5.5 leads the current snapshot at 68%, while more than half of tested models sit at 50-53%.

Context

GenAI code security is the governance problem that emerges when AI-generated output becomes routine in software delivery but verification still assumes a human-paced workflow. The core issue is not whether models can produce working code, but whether security controls can inspect, prioritise, and remediate that output quickly enough to prevent vulnerable code from moving downstream.

This matters to AppSec, DevSecOps, and platform teams because AI-assisted development shifts risk upstream. The control point moves from post-commit review to model selection, in-workflow validation, and policy around how generated code is accepted, tested, and tracked. In practice, the article describes a common enterprise condition, not an edge case: AI coding is already embedded in delivery, while governance is still catching up.

Key questions

Q: What breaks when AI coding tools are trusted without strong verification?

A: What breaks first is consistency. Without strong verification, teams inherit hidden defects, uneven quality, and release decisions based on confidence rather than evidence. Over time, that creates verification debt, where more code is generated faster than the organisation can responsibly assess and approve it.

Q: Why do AI coding tools change the AppSec bottleneck?

A: They increase code output faster than human reviewers can provide context, judgment, and validation. That means the bottleneck shifts from code creation to code review, and then to the controls that must work earlier than review to remain effective. Security teams should plan for that shift rather than assuming PR review will absorb it.

Q: How can security teams tell whether AI-generated code is actually safe?

A: They should look for security regression evidence, not just test pass rates. A codebase is safer only when the agent’s output survives threat-informed checks, review of privileged paths, and validation against the vulnerability classes most likely to recur in that repository.

Q: Should organisations standardise on one AI coding model or allow teams to choose?

A: Standardisation can reduce governance complexity, but only if the selected model has demonstrably better security performance for the code patterns the organisation uses. Otherwise, local choice may outperform central policy on risk. The decision should be based on measured vulnerability rates, not on developer familiarity or output style alone.

Technical breakdown

Why syntactically correct code can still be insecure

Large language models can generate code that compiles and runs while still embedding insecure patterns, because syntax and security are different properties. Syntax checks whether the code conforms to language rules. Security checks whether the code resists abuse, data exposure, injection, and privilege misuse in context. That is why a high pass rate for compilation can coexist with a much lower security pass rate. In GenAI code generation, the dangerous failure is false confidence: developers see working output and assume quality. Security verification has to evaluate data flow, trust boundaries, and language-specific weakness patterns, not just whether the code looks correct.

Practical implication: add security validation at the point of code generation, not only after code is committed.

How model choice becomes a security control

The report shows that model performance is not uniform, which makes model selection part of the security architecture. Some models produce fewer vulnerable outputs than others, and reasoning-capable models can outperform simpler alternatives on security tasks. That matters because the model is not just a productivity tool. It is a source of risk with measurable variance. Procurement, platform governance, and developer enablement therefore need to treat model evaluation like any other control decision: compare output quality, weakness patterns, and downstream remediation load, not only speed or cost.

Practical implication: evaluate AI coding models against security outcomes before standardising them across engineering teams.

Where vulnerability type drives verification priority

The strongest signal in the report is that different weakness classes behave very differently. Some categories, such as SQL injection and cryptographic misuse, are easier for models to handle consistently. Others, such as cross-site scripting and log injection, remain much weaker because they depend on application context and input handling paths. This means GenAI code security is not one broad problem with one control. It is a prioritisation problem. Teams need to know which classes of flaws the model misses most often so that review, test generation, and remediation effort can focus where error rates stay highest.

Practical implication: tune review depth by weakness class instead of applying the same control level to every AI-generated change.

NHI Mgmt Group analysis

GenAI code security is now a throughput governance problem. Once AI authors a large share of committed code, the limiting factor stops being generation and becomes verification capacity. Security programmes that still assume human-paced review are structurally out of alignment with the delivery model. The practitioner conclusion is straightforward: governance must move upstream with the code, not trail behind it.

Model selection is an AppSec decision, not a developer preference. When one model produces materially fewer vulnerable outputs than another, the difference translates directly into remediation volume, retest demand, and backlog pressure. That makes model governance part of software risk management, not just platform optimisation. Practitioners should treat model standardisation as a control choice with measurable security consequences.

Verification has to target failure patterns, not generic code quality. The report’s uneven results by vulnerability type show that AI output risk is concentrated, not random. Security teams should stop expecting a single quality gate to catch everything. The better control model is targeted validation against the weakness classes that remain consistently underperformed. The practitioner conclusion is to align AppSec testing depth with the model’s weakest failure modes.

Working code is not trusted code when the producer is probabilistic. The central governance assumption that breaks here is that functional output implies acceptable risk. That assumption fails for generated code because the same system can be reliable on syntax while inconsistent on security. The practitioner conclusion is that policy, review, and accountability must distinguish code that merely works from code that can be safely deployed.

AI coding scale changes the economics of AppSec. When half of committed code can be machine-authored, small security misses become large operational burdens. This is where the identity bridge matters: the software supply chain now includes machine-produced artefacts that need governed intake, traceability, and accountability. The practitioner conclusion is to align software assurance with AI-assisted production workflows, not legacy review volumes.

From our research library:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
• Read next: AI Coding Agents Security Guide

What this signals

GenAI code security now sits in the same governance lane as software supply chain risk. When AI-generated code becomes a routine input, AppSec teams need controls that evaluate provenance, review depth, and acceptance criteria together. The practical signal for practitioners is that code trust decisions are shifting left, toward the moment of generation rather than the moment of deployment.

Code security budgets are already moving toward this problem space. Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec. That spending pattern reflects a broader reality: organisations are funding control coverage because the volume and velocity of code-related risk no longer fit traditional review models.

For practitioners

• Set security thresholds for AI coding models Require model selection criteria to include security pass rates by weakness class, not only output quality or developer preference. Make the threshold part of platform approval for engineering teams that use generated code at scale.
• Move verification into the development workflow Run security checks at generation time and before merge so vulnerable output is caught while context is still available to the developer. Do not rely on post-commit review alone when AI is increasing code volume.
• Prioritise the weakest vulnerability classes first Tune review depth and testing emphasis toward the flaw types that remain hardest for models to avoid, especially where the article shows the pass rate falls sharply. This keeps remediation effort aligned to real model failure patterns.
• Govern AI-generated code as a supply input Track which models produce code, where that code enters delivery, and how often it is reworked or rejected. Treat generated code as a managed software input with policy, traceability, and accountability, not as ordinary developer output.

Key takeaways

• AI-assisted development is now large enough that security governance can no longer treat generated code as an edge case.
• The report’s core signal is operational, not theoretical: secure output is improving far more slowly than AI code adoption.
• AppSec teams need model selection, in-workflow verification, and targeted remediation to keep vulnerable output from scaling with productivity.

Key terms

• GenAI Code Security: GenAI code security is the discipline of governing code produced by generative AI so that it is not only functional, but also safe to ship. It combines model evaluation, workflow verification, remediation prioritisation, and policy controls around where AI-generated code is allowed to enter production.
• Security Pass Rate: Security pass rate is the proportion of evaluated outputs that meet a defined security standard without introducing a vulnerability. In code-generation contexts, it is a useful measure because it separates syntactic correctness from actual security quality and helps compare models under the same test conditions.
• Verification in the Workflow: Verification in the workflow means checking security before code leaves the developer process and moves downstream. It reduces reliance on slow, post-commit review cycles that were designed for human-paced change. For AI-assisted development, verification has to happen close to generation because risk scales with output volume.
• Model Selection For Security Tasks: Model selection for security tasks is the practice of choosing models based on workload fit rather than brand preference or default settings. It considers accuracy, latency, cost, tool behaviour, and policy constraints so that different tasks can use different approved models when needed.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is useful for practitioners who need to connect identity governance to broader security decisions across modern delivery pipelines.