AI's Offense Outpaces Its Defense

Generative AI has quickly moved from a noisy contributor to bug bounty programs to a formidable offensive tool, with models now routinely spotting zero-day vulnerabilities that have eluded human experts and traditional scanners for years. Yet that sharp offensive edge masks a persistent weakness on the defensive side: the same models, when asked to write or fix code, still leave basic security flaws at a rate that should give enterprise developers pause.

Recent studies in application security paint a split picture of AI's capabilities. While models impress with their ability to find and exploit flaws, they continue to generate and patch code with a level of insecurity that lags far behind their offensive prowess. This asymmetry, observed across multiple independent research efforts, raises a fundamental question for IT leaders betting on AI to accelerate software development: can a tool that excels at breaking code be trusted to build it?

The security gap in AI-generated code

A recent study from application security firm Veracode found that 44% of AI-generated code contains at least one known OWASP Top 10 vulnerability. While recent frontier models scored higher, no model achieved more than a 68% security pass rate, meaning every model generated insecure code roughly once every three tries.

More troubling, the average security pass rate for AI-generated code hardly improved across four study snapshots Veracode performed over the past year, which combined tested more than 100 model versions. Meanwhile, all tested models produced syntax-correct code 99% of the time, highlighting a stark divide between the ease of producing code that compiles and the difficulty of making it secure.

Offense is easier to verify

“Why are they getting better at syntax? Why are they getting better at writing exploit code yet not getting better at writing secure code?” asks Chris Wysopal, chief security evangelist at Veracode, when discussing the results with CSO. “That is my question to [the AI labs], and that’s what we’re trying to measure.”

The imbalance may stem from how success is defined. Offensive success is relatively straightforward to verify: if an agent can reproduce or exploit a vulnerability, the result is concrete. Determining whether a patch closes every relevant exploitation vector and vulnerable code path, however, is far harder, and that ambiguity may be holding back defensive improvements.

Theory to practice: Xint's findings

July's research from Xint.io, a code security testing platform developed by Theori, used five AI models from Anthropic and OpenAI to vibe-code applications from scratch and re-architect an existing human-written application. Across 28 app variants, researchers found and validated 434 security flaws: 196 in newly generated codebases and 238 in the re-architected application.

“In general, we find that the most common type of flaws in AI-generated code are flaws where the code still compiles — so the code runs but will have embedded secrets or will use too many resources at scale,” Kay Kwak, product owner for Xint at Theori, tells CSO. “This is in part due to shortcuts/quick-starts in the training data; as well as developers asking for a feature without also explicitly asking for a guardrail. We also found that the larger and more complex the codebase is, the more likely for AI to lose track of fine-grained user permissions.”

Patching is even harder

Fixing existing code is no easier, according to research from 1Password’s Off-By-1 Labs, which tested the quality of patches generated by various models for six known vulnerabilities in complex open-source projects. Across over 6,000 runs, the average success rate for fully resolving the vulnerability without materially changing application behavior was just 26%. Over half of the LLM-generated patches either failed to resolve the vulnerability, introduced a new vulnerability, or both.

“Since our research looked at patching, we were observing more of an editing process than a net-new creation process,” Keith Hoodlet, head of 1Password’s Off-By-1 Labs, tells CSO. “As such, our research and the research from Veracode should be viewed as complementary, rather than assessing the same challenges. Having said that, we cite their research as an inspiration for our work, and both bodies of research directionally point toward similar conclusions.”

The amplification effect

Tests from Dutch software quality assurance firm Software Improvement Group (SIG) for its State of Software 2026 report found that AI-generated code produces roughly two times the security risk violations compared to human-written code. “We also found that 71% of all code, not just AI code, has a low degree of security controls,” Jasper Geurts, SIG’s CTO, tells CSO. “AI didn’t create the problem; it amplified it. Where organizations have measured and managed code quality, AI accelerates delivery. Where they haven’t, it accelerates technical debt and security exposure.”

Why training alone may not fix it

Simply feeding models more code may not solve the problem. Xint’s Kwak believes writing secure code is an inherently hard problem. “The difficulty isn’t specific to AI,” he says. “Software engineering has an underspecification problem: Nobody writes down everything the code must not do.”

Hoodlet points to a deeper limitation in how LLMs work. “The attention mechanisms, which are fundamental to the nature of how current LLMs function, may inhibit models from ever fully addressing the challenge of patching vulnerabilities,” he says. “In section 7.3 of the research paper, we observed situations where an agent’s patch only addressed a single code path from the proof-of-concept exploit, while missing character-for-character identical instances of the same bug in adjacent code paths. It’s unclear how much more training is required to produce better secure coding outcomes given this inherent limitation.”

Geurts thinks better training will help only at the margins because a model lacks an organization’s architecture, security policies, and threat model by default. Harnesses, he argues, can provide that context and embed deterministic checks into development workflows, while noting that “The harness is the operating system for AI agents. It’s where you put the constraints that make them reliable. Without it, AI is fast and convincing, even when it’s wrong.”

The promise of harnesses

Purpose-built harnesses are already showing results. For example, OpenAI partnered with Trail of Bits for a project called Patch the Planet, using AI to find and patch vulnerabilities in open-source projects. As of Aug. 11, the initiative listed 1,250 reported issues across 49 codebases, 271 authored fixes, and 146 patches accepted upstream.

Xint’s internal testing confirms the effect: bare prompted loops found between zero and one of 17 injected vulnerabilities in 208,000 lines of code, while models inside Xint’s harness found between 11 and 14. “The bare loops only ever opened 2.9% of the files, and you can’t find a bug in a file you never open,” Kwak notes.

SIG’s tests with Claude Sonnet 4.6, using its Sigrid Guardrails system through MCP as a mandatory security and quality gate, produced approximately 97% fewer high-risk security findings and achieved 24% higher maintainability scores.

Human oversight remains essential

Even the best harnesses cannot eliminate all risk. Validation gates and automated checks reduce the flow of defective code, but they do not transfer responsibility from the organization. As Geurts argues, the technology changes where human judgment is applied—focusing it on reviewing requirements, accepting residual risk, and deciding when to trust a machine's output—rather than replacing it.

Hoodlet echoes that sentiment, emphasizing the need for more research into how many iterations are required for robust patches. “If you run a workflow that moves from vulnerability discovery, to critic/judge, patching, and validation before going back through vulnerability discovery, do you need to repeat that process 10 times to achieve a 90% or better chance of generating a robust patch? Does it require a hundred iterations, or a thousand to achieve a robust patch outcome? That is something we're interested in taking a closer look at.”

Why it matters for your organization

For businesses adopting AI-assisted development, the message is clear: AI's offensive capabilities are advancing faster than its defensive ones, and that gap carries real risk. Deploying AI-generated code without rigorous guardrails means accepting a higher likelihood of vulnerabilities making it into production, and trusting AI to patch its own mistakes is still a gamble.

This suggests that the burden of responsibility will remain on enterprises for the foreseeable future. Organizations should invest in robust development pipelines that include automated security scanning, code review, and human oversight—not because AI is doomed to fail, but because its current trajectory demands it.