Capital One Just Open-Sourced an AI-Powered Code Security Scanner
Capital One just open-sourced VulnHunter, an AI code security scanner that argues with itself to cut false positives and catch real vulnerabilities.
Table of Contents
A Fortune 100 bank just gave away its internal AI security tool for free. Not because it's feeling generous. Because the problem it solves is so big, and growing so fast, that keeping it private made no sense.
VulnHunter landed on GitHub on 16 July 2026. Capital One built it to catch vulnerabilities in code, specifically the kind of code that AI assistants are pumping out at a volume no human review team can keep pace with. The tool doesn't just scan. It thinks like an attacker, works forward from entry points, and then actively tries to disprove its own findings. That last bit, the falsification engine, is the clever part. Traditional SAST tools flood you with false positives. VulnHunter argues with itself before it bothers a human.
But here's the thing nobody's saying out loud: the fact that a bank had to build this at all is an indictment of the entire "generate first, audit later" model.
TL;DR: Capital One open-sourced VulnHunter, an agentic AI security scanner that uses attacker-perspective analysis and a falsification engine to find real vulnerabilities in AI-generated code. It exists because traditional SAST tools can't handle the volume, or the novel bug patterns, that AI coding tools produce. When a Fortune 100 bank builds and gives away a tool to audit AI output, it's a signal: the governance-free generation model is broken. Governed no-code platforms largely sidestep the problem VulnHunter exists to solve.
What is VulnHunter, anyway?
It's an agentic AI security tool, meaning it doesn't just pattern-match against a database of known vulnerabilities. It takes the perspective of an actual attacker, traces paths from entry points through the codebase, and works out what's actually exploitable. Then its falsification engine actively tries to prove its own conclusions wrong. If it succeeds, the finding gets discarded before it ever reaches a developer.
That last part matters more than you'd think. Anyone who's run a SAST scanner on a real codebase knows the pain: thousands of findings, most of them irrelevant, and somewhere in the noise maybe, just maybe, something that'd actually get you owned. The industry has normalised this. "Just triage the alerts." Nobody has time to triage the alerts.
Capital One open-sourced it on GitHub under the Apache 2.0 licence. The repo is at `capitalone/vulnhunter`. Go look. It's real.
Why does a bank need to build an AI code auditor?
Because the numbers are getting stupid.
Georgia Tech's Vibe Security Radar project tracked 35 CVEs in March 2026 alone that were directly attributable to AI coding tools. Command injection. Authentication bypass. Server-side request forgery. These aren't typos. They're design flaws baked in from the moment an AI agent decided how authentication should work. As Hanqing Zhao, the graduate researcher running the project, put it: "When an agent builds something without authentication, that's not a typo. It's a design flaw baked in from the start."
March 2026 had more AI-attributable CVEs than all of 2025 combined. The trajectory isn't linear. It's hockey-sticking.
Meanwhile, Microsoft patched 622 vulnerabilities in its July Patch Tuesday, a new record. Two of them were zero-days under active exploitation. That was two days before VulnHunter shipped.
The context here is that AI code generation is the default now. Claude Code, Copilot, Cursor. Developers aren't dabbling with these tools, they're building production systems with them. And the code these tools produce shares bug DNA. Zhao again: "Millions of developers using the same models means the same bugs showing up across different projects. Find one pattern in one AI codebase, you can scan for it across thousands of repositories."
Capital One saw this coming. They run one of the largest AWS deployments in financial services. They have AI-assisted development pipelines. They looked at their existing SAST tooling and realised it was about as useful as a bicycle pump on a burst dam.
So they built VulnHunter.
Doesn't this prove the "generate first, audit later" model is broken?
I'd argue it does, yes.
The entire premise of vibe coding, prompt an AI, get code, ship it, assumes you can catch the problems later. Static analysis. Peer review. Penetration testing. But the volume problem breaks every step of that pipeline. When AI can generate a feature in thirty seconds that would've taken a developer four hours, the review step doesn't get four hours. It gets skipped. That's the whole appeal.
So what happens? Organisations build expensive, sophisticated remediation layers. They train security-focused AIs to audit general-purpose AIs. They open-source those tools so other organisations can also audit the output of the same general-purpose AIs. It's an arms race where both sides are running on the same underlying models.
There's a simpler approach. Don't generate code that needs auditing in the first place.
What does this mean for no-code?
Here's where I get opinionated.
Governed no-code platforms like Stacker and Bubble are largely insulated from this problem. Not because they're "simpler." Because the security model is architectural, not remedial.
When you build on a governed platform, every action inherits permissions. The runtime is controlled. Authentication isn't something an AI agent might or might not remember to include. On most governed platforms it's already there, enforced by the platform, and the builder configures it declaratively. You're far less likely to accidentally skip input sanitisation because the platform handles it by default. It's much harder to introduce a command injection vulnerability because there's typically no arbitrary code execution path to inject into.
The attack surface stops being "every line of generated code" and becomes "the platform's API." And the platform vendor, not the individual builder, carries most of the security burden for that surface.
I'm not saying governed no-code platforms are immune to vulnerabilities. They're not. But the class of problem VulnHunter exists to solve, AI-generated code with novel, repeating vulnerability patterns at impossible scale, rarely arises at that same scale. It's a lot harder to rack up 35 CVEs in a month from code nobody wrote.
This is the structural advantage nobody talks about in the no-code-versus-AI-coding debate. AI coding tools optimise for generation speed. No-code platforms optimise for safe composition. They're different philosophies. And when the remediation cost of "fast" is "Fortune 100 banks open-sourcing AI security tools to keep up," the trade-off starts looking less theoretical.
The takeaway:
Capital One didn't open-source VulnHunter because it was a nice weekend project. They did it because AI-generated code is creating vulnerabilities faster than the security industry can build tools to catch them, and they think the only way to solve that is collectively.
For no-code builders, the lesson is clearer than it's ever been. Every organisation now has a choice: generate raw code and build increasingly expensive audit infrastructure around it, or build on platforms where security is inherited by default. The former approach just produced a bank-sponsored open-source security tool.
That's not a win. That's a warning.
Want to read
more articles
like these?
Become a NoCode Member and get access to our community, discounts and - of course - our latest articles delivered straight to your inbox twice a month!


