Topic starter
02/08/2026 12:17 pm
TL;DR: OpenAI’s GPT-5 reasoning models reached a 72% secure-code pass rate in Veracode’s October 2025 benchmark, while most other providers stayed in the 50% to 59% range and persistent failures remained for XSS and log injection. Reasoning helps, but AI-generated code still needs human review, scanning, and runtime controls because insecure output remains common.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “GPT‑5 Pulls Ahead on Secure Code While Rivals Stall”.
By the numbers:
- 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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: AI coding assistants are improving, but the security gap has not closed, and benchmark gains do not remove the need for human verification.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:18 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: GPT-5 raises secure code scores, but AI coding risk remains