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 materially improved secure code generation, but most newer LLMs did not.

Why it matters: This matters because teams adopting AI coding assistants still need governance for code provenance, review, and validation, not just better model selection.

By the numbers:

• GPT-5 Mini achieved a 72% security pass rate, the highest Veracode recorded.
• GPT-5-chat scored just 52%, well below OpenAI’s reasoning variants.
• Cross-Site Scripting (CWE-80) scored below 14% on average.

👉 Read Veracode’s analysis of GPT-5 secure code performance and model comparisons

Context

AI coding assistants can improve developer throughput, but they do not automatically produce trustworthy code. The governance gap is that software teams often evaluate model output for correctness before they evaluate it for security, even when the code will be merged into production systems with real access paths and data exposure risk.

This article is primarily about AI code security, not identity governance in the narrow sense, but it has a clear identity and access angle: insecure generated code can create or embed weak authentication, dangerous secrets handling, and unsafe privilege assumptions. For security and IAM teams, the key question is how to treat AI-generated code as untrusted input inside development and delivery pipelines.

Key questions

Q: How should security teams govern AI-generated code in production pipelines?

A: Security teams should treat AI-generated code as a controlled identity event, not just a development artifact. Require human approval, traceable authorship, scoped workload identities, and evidence of intent before production promotion. The goal is to preserve provenance and limit blast radius when generated logic behaves unexpectedly.

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 do security teams get wrong about secure-code benchmark scores?

A: They often assume a higher benchmark score means safe deployment. In practice, a score only shows that the model avoided certain known vulnerability patterns in a test set. It does not prove the code is safe in a real system, where secrets, IAM, dependency risk, and runtime configuration can still create compromise paths.

Q: How can organisations tell whether an AI coding model is safe enough to use?

A: Use model-specific measures rather than generic vendor claims. Track pass rates by vulnerability class, compare reasoning and non-reasoning variants, and test the model on the languages and application patterns your teams actually ship. A model is only fit for use if it improves security outcomes in your environment without reducing review discipline.

Technical breakdown

Why reasoning models improve secure code output

Reasoning models perform an internal step that resembles code review before they produce an answer. That matters because insecure patterns often emerge when a model generates the first plausible completion from training data, especially when the prompt lacks full security context. A reasoning pass gives the model more opportunity to compare alternatives, reject obviously unsafe constructs, and preserve safer defaults. The effect is not perfect security, but it is a measurable change in how the model balances correctness and risk.

Practical implication: prefer reasoning-enabled coding models for security-sensitive tasks, then verify the output anyway.

Why XSS and log injection remain hard for LLMs

Cross-Site Scripting and log injection failures are different from simple syntax mistakes. They depend on whether a variable is tainted, whether output is contextually encoded, and whether the code path preserves trust boundaries across functions. LLMs do not reliably perform interprocedural dataflow analysis, so they can miss where untrusted input enters a later sink. Longer context windows help with recall, but they do not replace program analysis.

Practical implication: add SAST and code review controls that specifically check dataflow, encoding, and sink handling.

Why secure code scores still do not equal safe deployment

A pass rate measures whether a generated snippet avoids a benchmarked vulnerability pattern, not whether the code is safe in a real application. Secure code can still fail when it is combined with weak secrets handling, poor dependency choices, bad IAM assumptions, or insecure runtime configuration. That is why secure generation must be treated as one control layer in a broader software assurance chain, not as a substitute for security testing or architecture review.

Practical implication: validate AI-generated code with SCA, SAST, and deployment-time guardrails before release.

Threat narrative

Attacker objective: The attacker objective is to exploit insecure AI-generated code as a reliable route into application compromise, data exposure, or downstream privilege abuse.

1. Entry occurs when developers accept AI-generated code into a repository or application pipeline without full security review.
2. Escalation happens when insecure patterns such as XSS, log injection, or unsafe handling of untrusted input are promoted into reusable application logic.
3. Impact follows when those flaws are deployed into production and become execution, data exposure, or privilege abuse paths.

NHI Mgmt Group analysis

AI code security is becoming a control-plane problem, not a model-quality problem. Veracode’s results show that better reasoning changes output quality, but it does not remove the governance requirement to validate code before it reaches production. The real issue is that AI code assistants now sit inside software delivery pipelines that already depend on identity, access, and trust decisions. Practitioners should treat AI-generated code as a governed artifact, not a trusted author.

Secure code generation does not remove identity and secrets risk from the development lifecycle. The article’s core finding is about vulnerabilities, but the operational risk extends to embedded credentials, unsafe API handling, and overconfident privilege assumptions in code. That means identity and PAM teams should pay attention to how AI-assisted development changes secret sprawl, service account use, and access boundaries across CI/CD. The practical conclusion is that code security and identity governance now overlap earlier in the delivery chain.

Reasoning alignment creates a new benchmark for AI assurance. The gap between GPT-5 reasoning models and GPT-5-chat suggests that internal deliberation can improve secure coding behavior, but only within the bounds of the model’s training and policy design. That makes security a measurable AI quality attribute, not just a downstream defect rate. Security leaders should use this as a signal to demand model-specific assurance evidence, not generic claims about AI coding productivity.

Static analysis and runtime controls remain the decisive backstop. Even the best result here leaves a material share of insecure output, and the worst-performing patterns are the ones that become operational incidents when they reach production. AI code assistants therefore fit into an assurance stack, not a replacement stack. The practitioner takeaway is simple: secure generation helps, but verification and enforcement still carry the final control authority.

What this signals

Reasoning quality is becoming a governance signal, not just a coding preference. Teams that adopt AI coding assistants should now evaluate whether the model reduces vulnerable output in the specific languages and frameworks they actually use. A model that looks stronger in a benchmark can still be unsafe if it weakens review discipline or creates false confidence in downstream controls. For practitioners, the programme question is how to measure model output against real application risk rather than abstract productivity claims.

AI-assisted development widens the surface area where identity controls matter. Generated code can introduce credential handling mistakes, unsafe service account assumptions, and access paths that never existed in the original design. That pushes IAM, PAM, and secrets management further left into the development lifecycle, where they need to influence build, test, and release controls. The useful reference point is OWASP Agentic AI Top 10, because tool-using AI systems and code assistants both expand delegated trust in ways traditional controls do not fully see.

Secure code pass rates should be read alongside identity and secrets exposure risk. Better benchmark performance does not change the fact that AI-generated code may still leak tokens, mishandle API keys, or encode trust boundaries incorrectly. Programmes that already struggle with secret sprawl should expect AI-assisted development to amplify the problem unless they add scanning, policy enforcement, and ownership for generated artifacts. The operational priority is to connect software assurance to identity governance before AI code becomes normalised across the engineering estate.

For practitioners

• Adopt reasoning-enabled coding models for sensitive work Use reasoning variants for code that touches authentication, secrets, input validation, or data handling. Track security pass rate by model family and do not assume a newer model is safe by default.
• Require security validation before merge Run SAST, SCA, and review gates on all AI-generated code before it reaches main branches or release candidates. Focus checks on tainted input handling, encoding, and unsafe query construction.
• Treat generated code as untrusted input Apply the same scrutiny to AI-assisted code as to third-party contributions. Require provenance, reviewer accountability, and exception handling for snippets that introduce secrets, tokens, or service credentials.
• Measure model performance by vulnerability class Track outcomes separately for XSS, log injection, SQL injection, and crypto-related tasks so procurement and engineering teams can see where each model is strong or weak.

Key takeaways

• GPT-5 reasoning models improved secure code generation, but most newer LLMs did not move the needle.
• Persistent weaknesses in XSS and log injection show that model output still needs analysis, review, and scanning before deployment.
• AI coding assistants change the control model for software delivery, so identity, secrets, and application security teams must govern them together.

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.
• Secure code pass rate: Secure code pass rate is the share of benchmark tasks where a generated code answer avoids a known vulnerability pattern. It is useful for comparing models, but it does not prove the code is safe in a live application with real dependencies, secrets, and trust boundaries.
• AI-generated code as untrusted input: This is the governance stance that model output should be treated like any other external contribution until it has been validated. It means generated code must pass review, scanning, and policy checks before it is merged, deployed, or allowed to influence sensitive systems.

What's in the full report

Veracode’s full analysis covers the benchmark methodology and language-by-language results this post intentionally leaves for the source:

• The 80-task benchmark design across four programming languages and the release window used for comparison.
• Model-by-model score tables that show where GPT-5 reasoning variants outperformed non-reasoning counterparts.
• Vulnerability-class breakdowns for SQL injection, Cross-Site Scripting, log injection, and cryptographic handling.
• The update path from the July 2025 GenAI Code Security Report to the October 2025 dataset.

👉 The full Veracode analysis covers the benchmark details, language splits, and vulnerability-class results.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for teams that need stronger control over delegated access. It helps practitioners connect identity governance to the software and AI pipelines their programmes already depend on.