AI Code Security Report 2026: Veracode Stuck at 56% Pass Rate

Every model release since the first Veracode report has come with a better coding benchmark, and every one of them left the same question open: does the code get safer, or only more correct? Veracode's July 2026 answer is that the pass rate moved by one point in a year.

This post reads the report through four public sources: Veracode's own blog post and press release, SD Times' coverage, and the 2025 blog for comparison. I could not open the full report, so every figure below is attributed to one of those pages, and the method and limits get their own section. None of the numbers are independent: Veracode sells the scanner that produced them.

What Veracode measured, and what it did not

The press release says the programme has tracked more than 100 models across four testing snapshots, and that the summer 2026 leaderboard covers 11 of them. Models were given code-generation tasks across several languages and vulnerability categories under standardised conditions with no security-specific prompting. The press release adds that these were raw models, not agents or production setups with tooling, guardrails or human review.

The blog post and press release do not state the task count, the full language list, the scanner configuration or the pass criteria. The 2025 blog tested Java, Python, C# and JavaScript, but the 2026 pages I read do not repeat that list, so I will not assume it. Treat every figure as Veracode's result on Veracode's test set.

The headline: 56% pass, nearly 100% syntax

Veracode reports an average security pass rate of 56%, barely changed from 55% in the first report, and says roughly 44% of code generation tasks introduced a risky security vulnerability in tests. In the same tests, syntactic correctness is now close to 100%. The gap between the two is the finding: models learned to write code that compiles, and did not learn to write code that resists attack.

The 2025 blog reached the same conclusion with different numbers. It reported that 45% of code samples failed security tests and that newer, larger models improved functional correctness without improving security. So the 2026 report is a second data point on a flat line, not a new discovery. Co-founder Chris Wysopal frames the practical rule in the press release: treat AI-generated code like any unreviewed code, scan it and fix it before it ships.

Which models, sizes and styles score what

The report breaks the average down by model type. The table collects every cut I could verify across Veracode's press release and SD Times, with the authors' own commentary where they gave one.

Two readings are safe. First, the reasoning gap of five points is the largest structural effect in the table, and the authors themselves hedge it with the word may. Second, nothing about being a coding model or a big model earns a pass. Picking a model on a leaderboard is not a substitute for scanning its output.

The classes models fail: XSS and log injection

The pass rate hides a split. Veracode's blog gives four classes, and they sit at opposite ends. The last column is my reading of why, drawn from the CWE entries, and is not from the report.

The pattern fits what the CWE entries ask for. CWE-80 asks for output encoding that the downstream component can handle, and the OWASP cheat sheet says the right encoder depends on the context: HTML body, attribute or JavaScript. CWE-117 describes a log message built from external input without neutralising special elements. In both, the unsafe code is also the shortest code that does the job, and the task description never says the value is hostile.

One consistency check of my own: the 2025 blog said AI tools failed to defend against cross-site scripting in 86% of relevant samples, which is a 14% pass rate if you invert it. The 2026 figure is 15%. I am inverting a failure rate by hand, and the two reports may not count identically, so read it as a hint that XSS did not move, not as a measured trend.

Python at 63%, Java at 30%

SD Times and the press release both report the language spread: Python has the highest security pass rate at 63% and Java the lowest at 30%. Java is also the only language Veracode describes as improving consistently over the past year. The 2025 blog had Java failing 72% of the time, which is consistent with Java sitting at the bottom for two reports running.

The sources I read give no numbers for the other languages, so I cannot rank JavaScript or C# for you. What I can say is that a 33-point spread between languages is larger than any model-level difference in the table above. If your stack is Java, the language effect is bigger than the model you pick.

A named trade-off: what this report cannot tell you

Before you quote 56% in a planning meeting, here are the limits, each stated by the sources or following directly from them.

• It is a vendor result. Veracode sells scanning and a fix product, and the press release recommends its own tools. The test design is not independently audited in anything I read.
• Raw models only. The tests used no security prompting and no agent tooling, so a model told to be careful, or wrapped in a reviewer, may behave differently. The report does not measure that.
• Eleven models in the 2026 leaderboard, with one at 68% and the rest clustered. A single leader is a snapshot, as Veracode itself says of GPT-5.5.
• Pass rate counts tasks, not severity. A failed log injection task and a failed SQL injection task weigh the same in an average, though their risk to you will not.

None of this makes the direction wrong. Two reports a year apart from the same company both show security flat while correctness climbs. The honest claim is that this method found no improvement, which is a weaker and more defensible sentence than saying models are getting worse.

Gate the two classes that fail worst

Because the failures cluster, the cheapest control targets them. Below are the two shapes I would look for in any AI-assisted diff: a log line built by string interpolation, and an HTML injection escape hatch. The wrong versions are what an unprompted model tends to write when the task is just make it work.

// Wrong: the shape a model produces when nobody asks about security.
// A username of "bob\n2026-10-17T09:00:00Z INFO admin login ok" forges a
// second, fake log line (CWE-117, log forging).
logger.info(`login failed for ${req.body.username}`);

// Right: structured logging. The value travels as a JSON field, and
// JSON serialisation escapes the newline, so one event stays one line.
logger.info({ event: "login_failed", username: req.body.username });

// Wrong: React escapes text children, but this opts out of that.
// Untrusted HTML goes straight into the DOM (CWE-80).
<div dangerouslySetInnerHTML={{ __html: comment.body }} />;

// Right: render it as a text child and let the framework encode it.
<div>{comment.body}</div>;

// If you genuinely need rich HTML, sanitise first, then inject.
// import DOMPurify from "dompurify";
// <div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(comment.body) }} />

Then put a scanner that is not the model in front of the merge button. This CodeQL workflow uses the security-extended suite, which GitHub documents as the default suite plus lower severity and precision queries. Expect more noise than the default and tune it, rather than turning it off.

# .github/workflows/codeql.yml
# Gate AI-assisted pull requests on a scanner that is not the model.
name: codeql
on:
  pull_request:
    branches: [main]
jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write   # needed to upload SARIF results
    strategy:
      matrix:
        language: [javascript-typescript, python, java-kotlin]
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v4
        with:
          languages: ${{ matrix.language }}
          # security-extended = default suite plus lower severity and
          # precision queries, per GitHub's docs. Noisier, catches more.
          queries: security-extended
      - uses: github/codeql-action/analyze@v4

What to do on Monday

Veracode's own recommendations are to choose models with security in mind, verify code in the workflow, focus remediation on exploitable flaws and govern AI coding as a software input. Translated into a week of work:

1. Turn on a code scanner for pull requests in every repository where an assistant writes code, and make the check required.
2. Add XSS and log injection to the review checklist by name, since those are the two classes with the lowest pass rates in the report.
3. Search the codebase for existing escape hatches such as dangerouslySetInnerHTML and string-built log calls, and fix or justify each one.
4. If you run Java, scan harder. The language gap in the report is bigger than the model gap.
5. Write down which model and tool produced each change, so a later finding can be traced. Veracode's governance advice asks for exactly that accountability.

# A crude tripwire, not a scanner: list every XSS escape hatch and every
# string-built log call in the diff, so a human looks at them on purpose.
git diff origin/main...HEAD -U0 -- '*.tsx' '*.jsx' '*.ts' '*.js' \
  | grep -nE 'dangerouslySetInnerHTML|innerHTML|logger\.(info|warn|error)\(`' \
  || echo "no escape hatches in this diff"

The tripwire above is deliberately crude. It lists lines for a human to look at and finds nothing a real analyser would not, but it takes one minute to add to a review habit while the scanner is being approved.

The rule I take from this report: correctness is not evidence of safety. Models now compile almost always and pass security tests a little over half the time, and the weak spots are the classes that depend on context, XSS and log injection. Treat AI output as unreviewed code, scan it with something that is not the model, and read vendor pass rates as a method's result, not a law of nature.