Do We Build More Secure Things When AI Helps Build Them?

There is a question circling the industry right now, and it is one worth sitting with rather than answering too quickly: does AI in the development pipeline actually make the things we ship more secure, or does it mostly just give the bad actors a better toolkit?

The honest answer is probably both. Which is not a satisfying thing to say, but it happens to be true.

Let us start with the optimistic side, because there is genuine substance there. When AI tools are woven into the development process, whether that is code generation, static analysis, fuzzing, or formal verification, they can catch things that humans routinely miss. Not because developers are careless, but because reviewing ten thousand lines of C for a subtle integer overflow on a Friday afternoon is not something human brains are built for. AI does not get tired. It does not have a standup in fifteen minutes. It will flag the same class of vulnerability on line 7,412 that it flagged on line 3. That consistency alone is worth something.

Chip manufacturers and firmware teams are starting to apply similar thinking to hardware design. Formal verification assisted by machine learning, AI-guided fuzz testing of hardware description languages, automated taint analysis across RTL designs. These are not science fiction anymore. There are real teams doing this work on real silicon. The result is not perfect security, but it does raise the floor. And raising the floor matters, because most attackers are not nation-states with unlimited resources. Most attackers are opportunistic, and a higher floor means more of them hit a wall and move on.

There is also something to be said for supply chain visibility. AI-assisted tools are getting reasonably good at analyzing open source dependencies, spotting unusual patterns in commit histories, flagging packages that suddenly gained a new maintainer and changed their build pipeline on the same week. The kind of signals that a security engineer might catch if they had the time, but rarely do.

So yes, there is a real argument that AI raises the bar for defenders.

And then there is the other side.

The same capabilities that help a developer write safer code also help a threat actor write more dangerous exploits. Vulnerability research that used to take a skilled attacker weeks can now be compressed. Generating convincing phishing lures, crafting evasive malware, automating reconnaissance across large attack surfaces, producing working proof-of-concept code from a CVE description: all of this is faster now. The asymmetry that used to favor defenders, because building secure things is hard and time-consuming, is under pressure. Attackers are not constrained by release cycles, compliance reviews, or change management boards.

There is also a subtler problem. When developers lean heavily on AI-generated code without deeply understanding what they are shipping, the result can be code that looks correct, passes automated tests, and still carries assumptions that open up risk. Not because the AI is malicious, but because AI tools are optimizing for "working code" more than "provably safe code." Those are not always the same thing. A function that processes user input correctly in 99 scenarios might still be exploitable in the hundredth.

A recent formal verification study of 3,500 code artifacts generated by seven major language models found that more than half contained at least one exploitable vulnerability. The best-performing model still came in at a 48% vulnerability rate. No model scored better than a D. And asking the models to review their own output only reduced the rate by about four percentage points. They knew what vulnerable code looked like. They just kept generating it anyway.

The CVE Flood Is Real, and It Is Not Slowing Down

One way to read the state of the industry is to look at the numbers. In 2024, over 40,000 new CVEs were published, a 38% increase over 2023. That single year accounted for more than 15% of all CVEs ever recorded. 2025 closed at roughly 48,000, up another 20%. As of mid-May 2026, somewhere north of 25,000 new CVEs have already been published this year, running at around 190 per day, which is about 40% ahead of where 2025 was at the same point. FIRST's forecast for the full year 2026 is a median of roughly 59,000, with an upper bound that approaches 118,000 in extreme scenarios.

That last number is worth sitting with for a moment. Not because it is likely, but because the range itself tells you something. We are in a regime where the volume of vulnerabilities being disclosed is structurally outpacing any human team's ability to triage them by reading. The patch cycle was never designed for 190 new CVEs every day.

But here is something the raw numbers do not immediately tell you: a meaningful part of the increase is not purely more vulnerable code. It is more organizations reporting more bugs more thoroughly. The number of CVE Numbering Authorities, the organizations authorized to assign CVE identifiers, crossed 484 at the start of 2026. More CNAs means more coverage, and more coverage means things that would previously have gone untracked now get an identifier. That is actually good news for defenders who build on structured threat intelligence. It does mean, however, that raw CVE counts are not a clean signal of a worsening codebase. The signal is noisier than it looks.

What is not noisy is the exploitation speed data. In 2025, nearly a third of newly exploited vulnerabilities were weaponized either before public disclosure or within 24 hours of it, up from roughly 24% the year before. The window between "this vulnerability exists" and "someone is actively using it" is now sometimes measured in hours. That is not something a monthly patch cycle was designed to survive.

The nature of the vulnerabilities is shifting too. Missing authorization flaws, the kind where code simply skips permission checks, jumped 62% year over year in 2025. There is a reasonable argument that AI-generated code, which tends to prioritize functionality over access control, is contributing to that specific category. The code does what it is supposed to do. It just does not always ask whether you are allowed to ask.

The Triage Pipelines Are Already Buckling

The clearest signal that the volume problem is not theoretical came from two very different institutions in the last six weeks. The first was Linus Torvalds. In a weekly LKML post in mid-May 2026, he wrote that AI-generated bug reports have made the kernel's private security mailing list, the channel that has handled embargoed Linux vulnerabilities for years, almost entirely unmanageable. His exact words: "AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved." He went on, with characteristic directness, to say that anyone who actually wants to be useful should read the documentation, write a patch, and add some real value rather than forwarding raw model output to maintainers.

The volume figures behind that frustration, attributed by the coverage to kernel stable maintainer and HAProxy creator Willy Tarreau, are worth pausing on. In March 2024 the private security list was receiving roughly two to three reports a week. By May 2026 it was receiving five to ten reports a day. That is not a slow climb. That is a process designed for hand-curated, embargoed disclosure being asked to absorb the output of an entire industry of researchers running similar models against the same kernel, all filing privately, often duplicating each other without realizing it.

The second signal came from NIST. In mid-April 2026, the agency announced that it was changing how the National Vulnerability Database operates because it could no longer keep up with the inbound flow. CVE submissions had grown 263% between 2020 and 2025. NIST enriched nearly 42,000 CVEs in 2025, a 45% increase over its previous best year, and the first quarter of 2026 was already running 33% above the same quarter the year before. So NIST stopped trying to enrich everything. Going forward, analysis priority follows the CISA Known Exploited Vulnerabilities catalog first, then software in federal government use, then software designated critical under Executive Order 14028. Anything below that effectively waits. Older unenriched CVEs were quietly moved to a "Not Scheduled" status.

What is interesting is what the NIST announcement does not say. It does not name AI-generated submissions as a driver of the volume. It does not announce any AI-assisted triage on NIST's own side. It treats the growth as a fact to be managed rather than a phenomenon to be explained. That silence is itself informative. The national vulnerability database has effectively conceded that exhaustive analysis is over and has not publicly engaged with the question of why the firehose is what it is.

If the most disciplined triage pipeline in open source and the canonical national vulnerability database are both visibly buckling, the bottleneck has shifted. It is no longer about whether vulnerabilities can be found. It is about whether the humans on the other end can read what arrives, deduplicate it, reason about exploitability, and decide what to do, before something else lands on top of it.

The Real Shift Is Not the Models. It Is Who Can Run Them.

If the CVE numbers tell one part of the story, the democratization of capable AI is the part that does not show up cleanly in any chart yet.

Two years ago, running a model competitive with GPT-4 required either an API subscription or a rack of hardware most people do not have. That has changed, and it has changed faster than most people realize. The current generation of open-weight models, built around mixture-of-experts architectures, achieves frontier-class reasoning while activating only a fraction of their parameters on each token. A model like Qwen3.6-35B-A3B has 35 billion parameters total but runs with only about 3.5 billion active at a time. The practical consequence is that a reasonably capable security-relevant AI now fits on a MacBook with 64GB of RAM or a single consumer GPU, running entirely offline, with no logs, no rate limits, and no terms of service to worry about.

Claude and ChatGPT get better with each generation, and that matters for everyone using them through official APIs. But those services have guardrails, usage policies, and monitoring. The more strategically significant development is that models approaching their capability, running fully locally and without any of those controls, are now accessible to anyone willing to spend a few hundred dollars on hardware they probably already own. Researchers are already showing that a 30-billion parameter class model running on a single RTX 5090 or equivalent can handle reasoning tasks that were firmly in the cloud-only tier eighteen months ago.

This cuts both ways, as everything in this space does. A security researcher can now run sensitive incident response queries against a local model without sending customer data to a third-party API, which is genuinely useful and addresses real compliance concerns. But the same setup is equally available to someone doing vulnerability research with less benign intent. The capability is not locked behind subscriptions or enterprise agreements. It is a download and an Ollama command.

The combination of that accessibility with rapidly improving code-specific models creates something worth paying attention to. Models fine-tuned specifically for software exploitation and vulnerability discovery are a natural next step from models fine-tuned for coding. The tooling exists. The hardware is cheap enough. And the CVE corpus to train or fine-tune on is, as we have established, growing at roughly 190 entries per day.

AI-Tooled Pentests: Yesterday Maybe, Tomorrow I Am Not So Sure

The honest question is not whether AI-tooled pentesting is better than what came before. It clearly is. The question is whether it is good enough, and what "good enough" even means when the threat landscape is moving this fast.

Tools like Shannon, an open-source autonomous pentester built by Keygraph on top of Anthropic's Claude agent framework, represent a genuine step forward. It ingests your application's source code, maps data flows, deploys parallel agents hunting for OWASP-class vulnerabilities, and then actually exploits what it finds. Not flags. Exploits. Only confirmed, reproducible proof-of-concept vulnerabilities make it into the report. A full run takes around 90 minutes and costs roughly $50 in API tokens. On the XBOW benchmark it scored 96%, ahead of both human pentesters and competing commercial tools. That is not a toy.

And yet. Shannon is a white-box tool, meaning it requires source code access. That scopes it out of most external adversarial scenarios immediately. It lives in the DevSecOps lane, running against your own application before you ship, which is genuinely useful but is a different thing from a red team engagement. The benchmarks are structured around known OWASP vulnerability classes. The results are impressive precisely because those classes are well-defined, reproducible, and matchable against training data.

The harder categories remain stubbornly out of reach. Business logic flaws, exploit chains that cross system boundaries, vulnerabilities that only surface under specific sequences of authenticated user behavior, misconfigurations that are individually harmless but dangerous together: none of these respond well to any current AI-tooled approach, however capable the underlying model. The Verizon DBIR for 2025 frames it plainly: 82% of successfully exploited vulnerabilities involved human reasoning, contextual analysis, or exploit chaining. AI tools are getting good at the other 18%. That matters. But a security program that mistakes that 18% for comprehensive coverage is building on a floor and calling it a ceiling.

The trajectory is also worth thinking about carefully. Today's AI-tooled pentest is better than yesterday's automated scanner, which was better than manual spot-checks. Each generation raises the bar. But each generation also raises what attackers can do with the same tooling, unencumbered by scope agreements, authorization workflows, or report formatting. The gap between what AI-tooled testing can find and what a motivated adversary with the same AI can do is not obviously closing. It may be widening in the categories that matter most.

The right frame is probably this: AI-tooled pentesting is the new baseline layer. It is continuous, cheap, proof-based, and genuinely better than what most organizations had before. Run it on every commit. Treat it as a hygiene requirement. But do not mistake the baseline for the engagement. The creative, adversarial, contextual work that catches what attackers actually use is still a human problem, and the AI on the other side of that equation is improving at least as fast as the tools on yours.

What Actually Helps

So where does that leave us? Probably here: the manufacturers and security teams that come out ahead are the ones using AI to compress response time while keeping experienced humans in the loop for the things that require judgment. That means AI-assisted code review, not AI-only code review. Automated scanning as a continuous baseline, not as a substitute for a real adversarial test. Exploit windows that are now measured in hours mean that detection and response speed matter more than ever, and AI genuinely helps there.

What it does not mean is that any of this gets easier. The CVE flood is real and growing, partly because we are getting better at counting, but also because the tools that generate vulnerable code are the same tools developers are increasingly reaching for by default. The exploitation window is shrinking. The automated tools are better than they used to be and still not good enough for the hard problems. And the models capable of assisting with serious vulnerability research now run on hardware that fits in a home office.

It is the same force multiplier problem as always. The question is whether the people on the defensive side are being as honest about what that multiplier can and cannot do as the people on the other side clearly are.

And then there is the part nobody quite wants to say out loud. AI is increasingly writing the code, with the flaws baked in. AI is running the static analysis and the pentest against that code. AI on the other side is attacking it. AI is hunting for the vulnerabilities. AI is writing the CVE description, because no human can keep up with the volume. And AI is generating the patch. Each link in that chain is being optimized independently, by different teams, with different incentives, and each link is getting faster.

Which leaves one honest question. Where are the humans in any of that?