GPT-5 raises secure code scores, but AI coding risk remains

At a glance

What this is: Veracode’s October 2025 benchmark shows GPT-5 reasoning models outperform other LLMs on secure code generation, but the broader AI coding landscape still produces too many insecure outputs.

Why it matters: This matters because AI coding assistants are now part of the software supply chain, and IAM, AppSec, and platform teams need controls that treat model output as untrusted code, not approved code.

By the numbers:

• GPT-5 Mini achieved a 72% security pass rate, the highest Veracode recorded in the October 2025 benchmark.
• GPT-5 followed closely at a 70% security pass rate in the same benchmark.
• Most other models remained in the 50% to 59% security pass-rate range across the October 2025 update.
• Cross-site scripting models still scored below 14% on average, showing that some vulnerability classes remain especially hard for LLMs.

Context

AI coding assistants are changing the software development workflow, but secure output is still not the same as secure software. A model can generate syntactically correct code and still miss tainted data handling, unsafe logging, or inadequate sanitisation, which is why secure-code benchmarks matter to AppSec and platform governance.

This update is especially relevant where organisations are starting to treat AI-generated code as part of normal delivery pipelines. The governance question is no longer whether teams will use code assistants, but where human review, static analysis, and runtime protections sit in the control stack.

For identity teams, the intersection is indirect but real: code assistants are becoming production tools inside developer workflows, and those workflows often rely on secrets, tokens, service accounts, and privileged automation.

Key questions

Q: What should teams do first when AI-generated code is entering the pipeline?

A: Start by requiring human review for any AI-generated change that touches authentication, secrets, logging, or input handling. That first gate is important because model output can be syntactically correct while still embedding insecure assumptions. Once the review path is clear, add scanning and release controls so generated code cannot bypass normal engineering checks.

Q: Why do AI coding assistants still produce insecure code?

A: They learn patterns from large code corpora that contain both secure and insecure examples, and they do not reliably reason about all dataflow or trust-boundary issues. Where a task requires context-sensitive security judgment, the model can produce plausible code that still mishandles input, encoding, or privilege. Better reasoning helps, but it does not replace analysis.

Q: What are the signs that AI code assistant use is becoming a security problem?

A: Warning signs include developers bypassing security policy to use assistants, repeated acceptance of outdated or unsafe recommendations, and the appearance of sensitive data in generated output. Another signal is when teams use these tools informally outside approved workflows, creating a shadow LLM problem that security and compliance teams cannot see or govern effectively.

Q: How should organisations compare reasoning models with standard code assistants?

A: Compare them by how they affect vulnerability creation in your own stack, not by generic model capability. Reasoning models may reduce insecure patterns, but they still require the same verification controls. The practical decision is whether the lower risk justifies the extra latency and cost in your delivery workflow.

Technical breakdown

Why reasoning models reduce insecure code patterns

Reasoning-enabled LLMs appear to improve secure-code output because they do not jump straight from prompt to code. They generate intermediate internal steps, which functions like a lightweight code review before the answer is committed. That helps them catch obvious insecure patterns such as unsafe string concatenation, missing input handling, or brittle control flow. The result is not deterministic security, but a measurable reduction in careless output when compared with single-pass generation. This matters because model behaviour, not just model size, is shaping code quality.

Practical implication: Treat reasoning mode as one control layer, not a guarantee, and keep secure-code validation in the delivery pipeline.

Why XSS and log injection remain weak spots

Cross-site scripting and log injection are difficult for LLMs because both depend on recognising trust boundaries across multiple program steps. A model may produce code that looks reasonable in isolation, yet still fail to distinguish user-controlled strings from safe application data. That problem is fundamentally about dataflow and context, which LLMs do not reliably model the way a compiler or static analyser can. This is why benchmark gains in one vulnerability class do not generalise cleanly to others.

Practical implication: Use static analysis and secure coding review to catch tainted-input mistakes that the model cannot reliably infer.

How AI coding assistants fit into application security governance

AI coding assistants are now part of the software supply chain, so their output should be governed like any other untrusted contribution. The relevant control question is not whether the code was human-written or machine-generated, but whether it passed through the same verification gates before merge and release. In practical terms, that means code review, SAST, SCA, and runtime protections all remain necessary. The article’s central signal is that assistant quality varies enough that governance cannot assume baseline safety.

Practical implication: Anchor AI-assisted development to existing AppSec controls rather than creating a separate trust path for model-generated code.

Threat narrative

Attacker objective: Exploit insecure AI-generated code to introduce vulnerabilities that can be abused after deployment.

1. Entry occurs when developers or build systems accept AI-generated code into the delivery workflow without treating it as untrusted input.
2. Credential or control abuse can follow when insecure code handles secrets, tokens, or logging paths in ways the model did not recognise.
3. Impact appears when the insecure pattern reaches production and creates exploitable application flaws such as XSS, log injection, or weak data handling.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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

Reasoning quality is becoming a security variable, not just a productivity variable. The article shows that internal reasoning steps can materially improve secure-code outcomes, which means code assistant selection now affects application risk as well as developer speed. That does not make reasoning models safe by default, but it does move security quality into the procurement and governance conversation. Practitioners should evaluate AI coding tools by their effect on vulnerability generation, not only on developer throughput.

AI coding assistants create a new trust boundary inside the software delivery chain. Once model output is merged into repositories, the organisation has already accepted a form of machine-authored implementation risk. That shifts the security question from authorship to verification, and it makes human review, SAST, and runtime protections the real control points. Teams that do not formalise this boundary will overestimate the trustworthiness of generated code.

Cross-site scripting and log injection remain the clearest evidence that LLMs lack reliable taint reasoning. Those weaknesses are not edge cases, they are proof that language fluency does not equal security comprehension. The named concept here is taint-blind code generation, meaning code that looks plausible but fails to preserve input trust boundaries. Practitioners should assume this failure mode will persist wherever the model must reason across multiple execution steps.

Security governance for AI-assisted development must stay anchored in existing application controls. The benchmark results validate layered review, scanning, and runtime enforcement rather than replacing them with model choice. In identity-heavy environments, that also includes protecting service accounts, tokens, and secrets used by developer tooling and CI/CD workflows. The practical conclusion is that AI code generation belongs inside AppSec governance, not beside it.

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

Taint-blind code generation: the core governance problem is not that assistants write code badly, but that they write plausible code without reliably understanding where untrusted input must be contained. That means secure development teams should govern model output at the point of acceptance, not after the fact.

AI-assisted development is now a control-design issue for application security, because model quality varies by task and vulnerability class. Teams that already run code review and scanning should extend those gates to generated code rather than building a separate trust model for assistants.

The security signal is clear: as assistants enter more delivery pipelines, organisations will need tighter linkage between developer tooling permissions, repository controls, and secrets governance. The boundary around code generation is becoming a governance boundary around access and change.

For practitioners

• Enforce human review for AI-generated code Require manual approval for model-generated changes before merge, especially where code touches authentication, secrets handling, logging, or input validation.
• Run SAST on every AI-assisted commit Feed all generated or edited code through static analysis so tainted-input handling, unsafe sinks, and insecure patterns are caught before release.
• Add runtime protections for web-facing changes Pair assistant output with runtime controls such as WAF rules, input encoding, and defensive logging for application paths that the model may mis-handle.
• Limit assistant access to sensitive development assets Scope tokens, service accounts, and repository permissions used by AI coding tools so a compromised workflow cannot reach broader build or deployment systems.
• Benchmark assistants against your own risk profile Test the models your teams actually use against the languages, frameworks, and vulnerability classes that matter most to your environment.

Key takeaways

• AI coding assistants are improving, but the security gap has not closed, and benchmark gains do not remove the need for human verification.
• Reasoning models can reduce some insecure output, yet XSS and log injection still expose the limits of language models in trust-boundary reasoning.
• Treat assistant-generated code as untrusted input and keep it inside normal AppSec gates, including review, scanning, and runtime controls.

Key terms

• Reasoning model: A reasoning model is a language model that performs additional internal deliberation before producing output. In code generation, that extra step can improve the model’s ability to compare alternatives and avoid obviously unsafe patterns, although it still cannot replace security testing or architectural review.
• Taint-Blind Code Generation: Taint-blind code generation is the failure mode where code looks plausible but does not reliably preserve trust boundaries around user-controlled data. It shows up most clearly in sanitisation, logging, and multi-step application flows where the model lacks full dataflow context.
• Secure-Code Benchmark: A secure-code benchmark is a repeatable test set used to measure how often a model produces code that avoids known vulnerabilities. It is useful for comparing assistants, but the result only reflects the tasks tested, not overall production safety.
• Static analysis: Static analysis is the inspection of source code or configuration without executing it. It helps identify insecure patterns early, but its value depends on accuracy, timing, and whether the output is usable enough for developers to fix issues while they are still working on the code.

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 suitable for teams that need a practical framework for governing machine identities, developer tooling, and AI-enabled workflows.