Topic starter
02/08/2026 12:17 pm
TL;DR: GPT-5 Mini and GPT-5 topped Veracode’s October 2025 secure-code benchmark at 72% and 70%, but most other LLMs still clustered in the 50% to 59% range according to Veracode. That leaves AI-generated code dependent on review, scanning, and runtime gates before release.
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: 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.
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.
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.
Glossary terms: Reasoning model, Taint-Blind Code Generation, Secure-Code Benchmark, Static analysis
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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