Your Models Got Smarter. Your Code Didn't Get Safer

Veracode published its 2026 GenAI Code Security Report last week, and the headline number is one of the least-moved statistics in this industry: across the models tested, AI-generated code passed security checks 56% of the time. In the first edition of the report, that number was 55%.

Think about everything that happened between those two reports. Multiple frontier model generations. Benchmark records broken every few months. Agents that can carry a task for hours. And in that same window, the odds that a given piece of generated code introduces a known class of vulnerability barely changed — still roughly 44%.

If your security plan for AI-assisted development is "the models will get better," this is the data point that should end it.

Capability and security are on different curves

The report is blunt about the split. Syntax is effectively solved — modern models produce code that compiles nearly 100% of the time. Functional correctness keeps climbing. Security doesn't follow. The best model Veracode tested reached 68%; more than half sat in the low 50s. Bigger models did about as well as smaller ones. Coding-specialized models did no better than general-purpose ones.

The breakdown by vulnerability class explains why. Models are good at the flaws that have an obvious local fix: SQL injection passed 83% of the time, weak cryptography 87%. They're bad at the flaws that depend on context the model doesn't have — where the data came from, where it's going, who can reach it. Cross-site scripting passed 15% of the time. Log injection, 12%.

That's not a gap the next release closes. It's a gap between what's in the prompt and what's in your system.

The gap nobody owns

Now put that next to a second survey. Black Duck asked 831 engineers and DevOps professionals about AI coding tools earlier this year. Ninety-seven percent of teams are using them. Thirty percent have what they'd call a fully governed approach. A quarter have no defined policy at all.

So nearly everyone is generating code with a coin-flip security profile, and most are doing it without an agreed answer to basic questions: which tools are approved, what gets scanned, who reviews what, where agents are allowed to run.

Here's the number in that survey I'd put in front of a leadership team. Among the governed teams, 90% report a major efficiency gain from AI. Across everyone, it's 58%. Governance isn't the tax on the productivity gain. In this data, it's the thing that predicts it.

That matches what I see. Ungoverned teams don't move faster — they move the work. The same survey's top friction points were manual code review, security testing, and rework. Code that arrives fast and then sits in a security queue, or bounces back twice, hasn't been delivered faster. It's been generated faster.

What governance actually means at 50 engineers

Mid-size teams hear "governance" and picture a committee. It's four decisions, written down.

An approved-tools list with data rules. Which assistants, on which repos, with which data. One page. The point is that an engineer never has to guess.

Security scanning inside the loop, not after it. Static analysis and secrets detection should run where the code is generated — in the agent's sandbox or the pre-commit hook — so the model fixes its own findings before a human ever sees the diff. Scanning at the end of the pipeline turns every finding into rework.

Review rules by risk, not by author. Auth, input handling, anything touching logs or user-supplied data gets a human who knows the system. Those are exactly the classes where the models are weakest.

Agent permissions as a real design. What an agent can read, write, and reach is a security boundary. Treat it like one.

None of this slows a team down. It's what lets a team stop double-checking everything by hand.

The question to ask

When the next model ships, someone will ask whether it's more secure. The honest answer, on the evidence, is: about the same as the last one. The better question is whether your process assumes the code is safe or checks that it is.

If your leadership team hasn't agreed on what that policy should say, that's the conversation our executive AI brief is designed to start.