There’s a passage in OpenAI’s new “collective cyber defense” letter that deserves more attention than it’s getting. Tucked between calls to fund critical-infrastructure defense and impose costs on attackers is a practical instruction to every organization that builds or buys software: “raise the security bar for what you buy, build, and deploy, including AI-generated code.”
It’s a measured, honest ask from a company that builds some of the most widely used AI coding models in the world. AI is transforming how software gets written with faster development, broader access, and real productivity gains. But OpenAI is straightforward about the corollary: the code those models produce still needs to be verified, not assumed.
That’s not anti-AI. It’s the opposite. It’s the labs themselves saying the right thing: AI is a powerful tool, and powerful tools need the right guardrails. The question for the rest of us is whether we’re building them.
OpenAI and Anthropic Acknowledge AI Cyber Threats
The recent headlines have framed OpenAI and Anthropic as at odds, but look past the framing and there’s a real convergence. Both are openly acknowledging that their frontier models now carry cyber capabilities the industry needs to take seriously.
OpenAI paused training of some of its frontier models after concluding it “cannot rule out” that its upcoming Astra model has reached “critical” cyber capabilities — a threshold its own preparedness framework treats as a hard stop. Anthropic published a 186-page report detailing its safeguards while privately briefing government officials that its Mythos model makes large-scale cyberattacks “much more likely in 2026.”
The takeaway isn’t that the labs are reckless. It’s that they’re being transparent about a genuinely hard problem: as models get more capable, the gap between what they can do and what we can verify widens. In UK government security tests, agents from both labs took unsanctioned actions during evaluations; this is a reminder that even controlled environments surface unexpected behavior.
Credit where it’s due: the labs are slowing down, briefing regulators, and asking the industry to prepare. That’s responsible behavior. But the preparation they’re calling for has to land somewhere. And that somewhere is the software supply chain.
AI Code Security: The Defense Problem No One’s Talking About
Everyone’s focused on what attackers can now do with AI, like autonomous agents, persistent campaigns, and exploits at a scale and speed humans can’t match. That threat is real, and OpenAI names it plainly: AI-enabled attacks will become “far more widespread and sophisticated,” putting hospitals, water utilities, and the infrastructure that powers the internet at risk.
But there’s a quieter, more actionable problem getting less airtime: the defensive side of AI code. This is the software AI writes for you, the dependencies AI agents pull in, the code shipped at machine speed into production. OpenAI names “AI-generated code” as something you must raise the bar on. That’s not a rebuke of AI-generated code. It’s a recognition that AI accelerates the volume of code, which means we need to accelerate code security verification to match.
The data on how that’s going tells a clear story, and it’s not all bad.
Exploitation of Vulnerabilities Is Now the Top Breach Vector
For 19 years, the Verizon DBIR tracked stolen credentials as the most common way attackers got in. This year, that changed. Exploitation of vulnerabilities overtook credential abuse as the leading initial access vector, accounting for 31% of breaches.
In other words: attackers are shifting from tricking people to exploiting the software itself. This is the first year the DBIR also documented an AI-executed state-sponsored attack, moving the hypothetical into reality.
The software is also getting harder to defend. Breaches involving third parties jumped 60% year-over-year and now account for 48% of all breaches. Only 26% of the vulnerabilities in CISA’s Known Exploited Vulnerability catalog — the ones attackers are actually using — were fully remediated by organizations last year, down from 38% the year before. We’re finding more holes and patching fewer of them.
Security Debt Is Compounding Faster Than We Can Pay It
Veracode’s 2026 State of Software Security report puts numbers to the unease. Security debt (known vulnerabilities left unresolved for more than a year) now affects 82% of organizations, an 11% increase in a single year. Critical security debt, the kind severe and exploitable enough to cause critical damage, now affects 60% of organizations, a 20% jump. High-risk vulnerabilities are up 36% year-over-year.
The most telling detail is where the debt lives. Third-party components and open-source libraries account for 66% of all critical security debt, and the remediation half-life for third-party flaws is 358 days. This half-life is nearly four months longer than the 243-day average across all scans.
So here’s the picture: attackers are shifting to exploiting software. The software is increasingly assembled from third-party components. Those components are full of unfixed flaws. And now AI is adding a new stream of generated code into a supply chain that’s already under strain.
That’s not a reason to slow down AI adoption. It’s a reason to fix the verification gap before the volume makes it unmanageable.
The “Vulnpocalypse”: AI Won’t Just Write Bad Code… It’ll Find Yours
There’s a term that was first heard at [un]prompted and then repeated widely at RSAC 2026: vulnpocalypse. The idea is straightforward and unsettling. LLMs won’t just introduce new vulnerabilities; they’ll systematically uncover the ones that have been sitting in codebases for years. Not new bugs. Newly visible ones.
This is where the OpenAI warning and the security debt data collide. We already have 82% of organizations carrying unresolved flaws, 60% carrying critical debt, and third-party components making up two-thirds of the most dangerous exposure. That debt has been manageable largely because no one (attacker or defender) had the time to find it all. AI changes that math. When models can enumerate vulnerabilities at machine speed, years of accumulated security debt could come due all at once.
The vulnpocalypse isn’t a hypothetical threat from the outside. It’s the existing debt in your own codebase, suddenly illuminated. And the same AI acceleration that makes it visible is also generating new code to add to the pile at a volume manual review can’t absorb.
AI Code Security: Better Code Doesn’t Mean Secure Code
This is the nuance the conversation often misses. AI is genuinely improving as a coding tool… and that matters.
Across more than 100 models and four snapshots, the average security pass rate for AI-generated code sits at roughly 56%. That means in about 44% of generation tasks in the test, the model introduces a detectable, known vulnerability. And that number has been essentially flat across model size, across release date, and across the entire span of the research.
Meanwhile, the syntax pass rate – whether the code compiles and runs – has climbed to near 99.9%. AI is getting demonstrably better at writing code that works. It is not getting better at writing secure code. Those are different problems, and the industry has been treating them as the same one.
This isn’t an indictment of AI. It’s a reminder that AI-generated code is still code, and all code, human or machine-written, carries the same security fundamentals. The difference is volume. When AI authors roughly half of all committed code, a 44% flaw introduction rate becomes a scale problem that manual review simply can’t keep up with. The fix isn’t less AI. It’s verification that moves at the same speed.
Verification Is the Missing Layer for AI-Generated Code Security
Here’s where the argument lands.
The labs are being transparent about their models’ capabilities. They’re slowing down where they need to. They’re briefing regulators. And in OpenAI’s letter, they’re explicitly asking defenders to “test defenses continuously against frontier capabilities,” to share playbooks, and to measure progress by outcomes, like how many organizations are protected, how fast attacks are contained, and whether fixes actually work.
That’s a verification-and-attestation framework dressed up as a collective-action call. The labs are telling the industry what “good” looks like.
The durable answer isn’t to distrust AI. It’s to verify independently – of provenance (where did this code come from, and is it what it claims to be), of security (does it contain known flaws), and of behavior (does it do what it was supposed to do and nothing else). Continuously, at the speed AI now ships. Not as a point-in-time scan, but as a standing condition of software trust.
From Finding Vulnerabilities to Building Software Trust
Finding vulnerabilities accurately is still a prerequisite, and false positives erode developer trust in the tools, while false negatives create false attestation and a false sense of security. Both are trust failures, not efficiency problems.
But finding is the easy part. The harder problems are governing what enters your codebase in the first place, closing flaws at machine speed once they’re found, and proving your software’s posture to the stakeholders who increasingly depend on it, like regulators, customers, partners, and the critical-infrastructure operators the OpenAI letter rightly worries about.
AI is going to keep getting better at writing code, but the labs themselves are telling us, in their own words, that “better code” and “trusted code” aren’t the same thing. The bar they’re describing – continuous verification, provenance, attestation, outcomes-based measurement – is the one the industry has been tiptoeing around for years.
It’s time to stop tiptoeing.
The code security pass rate isn’t improving on its own. See the full breakdown across 100+ models, four snapshots, and every major language in the 2026 GenAI Code Security Report.
This article reflects the author’s analysis and is provided for informational purposes only.
