10decoders
Syntax Got Solved. Security Did Not.
Modern AI coding models write code that compiles and runs almost every time now. That part of the problem is finished. What has not moved at anywhere near the same pace is whether that code is safe to put in front of real users, and the gap between the two has become the defining quality risk of 2026.
Veracode's latest testing put the average security pass rate at 56 percent across more than 100 models, checked against a wide set of vulnerability classes, languages, and coding tasks. Roughly 44 percent of tested code-generation tasks introduced a known, exploitable vulnerability, even though the code itself worked. Syntactic correctness sits close to 100 percent on the same tests. That spread means a pull request can clear every functional check a team has and still ship a security defect nobody looked for, because the review process was built to answer whether the code runs, not whether it can be exploited.
The failure is not uniform across vulnerability types, and that is the part most QE teams miss. Models handle well-documented, pattern-based risks reasonably well: SQL injection resolves correctly about 83 percent of the time, and cryptographic implementation checks pass at 87 percent, because those patterns are heavily represented in training data with a clear right and wrong answer. Cross-site scripting and log injection are a different story, correct only 15 percent and 12 percent of the time respectively, because catching them requires tracing how untrusted input actually moves through an application rather than recognizing a fixed code shape. That is exactly the kind of context a generic regression suite, tuned for functional behavior, was never built to test.
A passing build has never meant a safe build. AI just made that distinction easier to forget.
Where AI-Written Code Actually Fails a Security Review
| Vulnerability class | Why it slips past standard QE | Severity |
|---|---|---|
| Cross-site scripting (AI models pass only 15% of tests, per Veracode 2026) | Catching it requires tracking untrusted input across templates and the DOM, not recognizing a fixed code pattern | Critical |
| Log injection (AI models pass only 12% of tests, per Veracode 2026) | Rarely treated as a security-relevant sink during functional test design | Critical |
| Broken access control (OWASP's most common production vulnerability class since 2021) | Functional tests confirm an endpoint works, rarely who is allowed to call it | High |
| SQL injection (AI models pass 83% of tests, per Veracode 2026) | Well represented in training data as a pattern with one clear correct answer | Moderate |
| Cryptographic implementation (AI models pass 87% of tests, per Veracode 2026) | Standard library calls are learned well, and custom crypto logic is the exception that still slips through | Lower |
Not sure where your AI-generated code has security testing gaps?
10decoders runs AI code security assessments that map your current CI gates against the vulnerability classes AI models actually miss, then show exactly where a scanner, a policy, or a human reviewer needs to sit in the pipeline.
Book a Free AI Assessment →Why "It Passed CI" Stopped Being Good Enough
Most CI pipelines were built around a functional-regression mindset: run the unit tests, run the integration tests, check the build, ship it. Security scanning got added later, and in a lot of organizations it still runs as a periodic audit rather than a merge gate, checked weekly or before a release instead of on every commit. Veracode's 2026 State of Software Security research shows what that lag costs at scale: security debt now affects 82 percent of organizations, critical security debt affects 60 percent, and high-risk vulnerabilities are up 36 percent year over year. AI did not create that backlog on its own, but it is filling it faster than most teams built the process to clear it.
Model choice compounds the problem, because it turns out to be a governance decision, not a preference. The strongest model in Veracode's 2026 testing, GPT-5.5, leads at a 68 percent security pass rate, which still means it fails almost one in three security-relevant tasks. More than half of the models tested sit at 50 to 53 percent. Coding-specialized models do not outperform general-purpose ones on security, averaging 51 percent against 52 percent. Reasoning models show a modest edge, 56 percent versus 51 percent for non-reasoning models, but even that gap leaves nearly half of their output unverified by default. No model in the current field removes the need for a testing pipeline built to catch what it misses.
Security as an Afterthought
Manual review catches obvious functional bugs. Security scanning runs occasionally, if at all, on AI-touched code, and findings surface in production instead of in CI.
Gated but Generic
SAST and DAST are wired into CI, but tuned for human-authored patterns with no per-model policy, so weak classes like cross-site scripting and log injection still slip through.
Verified by Design
Security testing runs on every AI-touched commit, model choice is a documented governance decision, and remediation is tracked and owned the same way functional defects are.
Before You Trust AI-Generated Code in Production
Most of what separates a mature security testing process from an exposed one is discipline, not new tooling. The checklist below is what to confirm is actually in place before AI-generated code reaches a production branch.
AI Code Security Testing Checklist
The cheapest time to catch an exploit is before it has a commit hash.
What to Do This Week
01 Add a security gate to the AI-code path specifically
Wire SAST, and DAST for anything touching an API boundary, into the CI step that runs on AI-flagged or AI-authored commits. Most git platforms can tag these automatically. Block merge on a failed scan the same way a broken unit test already blocks merge, and start with the highest-traffic service instead of trying to cover every repository in one week.
02 Compare your scanner's coverage against the classes AI misses most
Check whether your current SAST and DAST configuration actually tests for cross-site scripting and log injection specifically, not just SQL injection, which most default rule sets already catch well. Those two classes are where AI-generated code fails most often, and any gap found this week is worth closing with a rule change or a manual review step.
03 Put a written policy on which AI models can touch which codebase
If a team is using a model in the 50 to 53 percent security pass-rate range on a production-facing service, that should be a decision someone can name, not an artifact of whichever tool a developer's IDE plugin defaulted to. Document current model usage repo by repo this week and flag any mismatch between a model's risk profile and the service it touches.
04 Name an owner for the AI-code security backlog
Assign a specific person or a weekly rotation to triage findings from AI-touched commits, with a stated SLA for critical and high findings, so flagged vulnerabilities stop aging silently in a shared queue nobody is accountable for.
Let 10decoders Test-Harden Your AI Code Pipeline
Our AI code security assessment maps your current CI gates against the vulnerability classes AI models actually miss, benchmarks the models your teams already use, and hands you a remediation plan with named owners, not just a scan report.