Your coding model is also a vulnerability scanner

You bought a coding assistant to ship features faster. Nobody sold you a vulnerability scanner. You got one anyway, and so did everyone else.

Writing code and finding the holes in code are not adjacent skills that happen to correlate. Past a certain level of competence they are the same skill, pointed in two directions. A model good enough to implement session handling is good enough to notice that yours expires nothing. That was a prediction a couple of years ago. It is now shipped products, published CVE identifiers and at least one documented attack campaign. This guide is for someone who owns a codebase and does not own a security team: a solo developer, a freelancer shipping client work, a small team with production traffic and no application-security hire. If you have a security function with a budget, a threat model and a pentest contract, this sits below your floor and you can skip it.

The capability is measured, not marketed

The evidence arrives from three independent directions, which is the reason to treat it as a property of the technology rather than one company’s launch copy.

OpenAI announced Aardvark on 30 October 2025, an agent built on GPT-5 that “continuously analyzes source code repositories to identify vulnerabilities, assess exploitability, prioritize severity, and propose targeted patches” [6]. Against benchmark repositories containing known and deliberately introduced bugs, it identified 92 percent of them [6]. Pointed at real open-source projects, its findings produced ten CVE identifiers [6]. On 6 March 2026 OpenAI renamed it Codex Security and moved it from private beta to a research preview for ChatGPT Enterprise, Business and Edu customers, with free usage for the month that followed [6]. Whatever else that is, it is a security researcher sold as a seat add-on.

Google’s Big Sleep, built by DeepMind with Project Zero, found its first real-world vulnerability by November 2024 [7]. It later found CVE-2025-6965 in SQLite, which Google describes as “a critical security flaw, and one that was known only to threat actors” [7]. What happened next is the part worth reading twice. Google says that “through the combination of threat intelligence and Big Sleep, Google was able to actually predict that a vulnerability was imminently going to be used and we were able to cut it off beforehand”, and believes this is “the first time an AI agent has been used to directly foil efforts to exploit a vulnerability in the wild” [7].

The third direction is a contest rather than a product. DARPA’s AI Cyber Challenge ran automated systems against code seeded with 63 synthetic vulnerabilities. The systems discovered 54 of them, 86 percent of the total, and patched 68 percent of the total [8]. Team Atlanta won $4 million with 43 found and 31 patched, Trail of Bits took second with 28 found and 19 patched, and Theori took third with 34 found and 20 patched [8]. Results were announced at DEF CON 33 in 2025 [8]. No marketing department set those numbers, and the gap between the found column and the patched column is the honest part.

Both sides got the capability in the same season

There is no arrangement where defenders receive this and attackers do not.

In mid-September 2025 Anthropic detected a Chinese state-sponsored group using Claude Code to run an espionage campaign against roughly 30 targets spanning technology companies, financial institutions, chemical manufacturers and government agencies, with successful infiltration in a small number of cases [5]. The model performed reconnaissance, identified vulnerabilities, wrote exploit code, harvested credentials, exfiltrated data and produced the attack documentation [5]. Anthropic’s assessment is that the AI executed 80 to 90 percent of the campaign, with human intervention needed only at “perhaps 4-6 critical decision points per hacking campaign” [5]. At peak the system made “thousands of requests, often multiple per second” [5]. Anthropic characterises it as “the first documented case of a large-scale cyberattack executed without substantial human intervention” [5].

Set that beside Big Sleep and the situation resolves. The same year an AI agent first cut off a live exploitation attempt, an AI agent first ran most of a real intrusion campaign. Anthropic’s own sentence is the cleanest statement of the constraint: “The very abilities that allow Claude to be used in these attacks also make it crucial for cyber defense” [5]. That is a description, not a slogan. Capability does not arrive on the defensive side first and wait politely for policy to catch up. The variable you actually control is narrow: whether a competent review has been run over your code recently, and whether the person who ran it was you.

Run the pass on your own repository this week

The tooling is unglamorous and already installed for most readers.

In Claude Code, /security-review runs an on-demand security pass over the changes on your current branch [1]. Anthropic’s description of what it checks is specific: SQL injection risks, cross-site scripting, authentication and authorization flaws, insecure data handling and dependency vulnerabilities [2]. There is a matching GitHub Action that “takes security reviews a step further by automatically analyzing every pull request when it’s opened”, applying filtering rules you configure and posting inline comments with findings and suggested fixes [2]. A separate security guidance plugin has Claude review and fix vulnerabilities in its own changes during the session, which catches the specific failure mode of an agent introducing a flaw and then reviewing its own work approvingly [1].

If your team is on ChatGPT Enterprise, Business or Edu, Codex Security covers similar ground through threat modelling, commit scanning, sandboxed validation of whether a finding is actually exploitable and patch generation [6]. That validation step matters more than the finding count. A list of unranked maybes is worse than useless to a one-person team, because triage time is the resource you are short of.

Sequence it in two stages. Run one full pass over the whole codebase, treat the output as a backlog rather than a to-do list, and fix by exploitability rather than by severity label. Then wire the per-pull-request check so the backlog stops growing. Running the full pass monthly after that is enough for most small codebases; running it after every dependency bump is better.

The bill is small enough to stop being the reason

Token cost is no longer a defensible excuse for skipping this.

Claude Sonnet 5 costs $2 per million input tokens and $10 per million output [3]. Claude Opus 5 is $5 and $25, and Claude Haiku 4.5 is $1 and $5 [3]. Batch processing takes 50 percent off both input and output, so a Sonnet 5 batch job runs at $1 and $5 [3]. Prompt caching drops a cache hit to 0.1 times the base input price, which on Sonnet 5 is $0.20 per million tokens, and re-reading the same codebase is exactly the case caching was built for [3].

Plug your own numbers in and the answer for a typical small codebase lands in single-digit dollars per month. Your real cost is the hour you spend reading findings and deciding which three matter. Budget for that hour, not for the tokens.

The permissions you grant the reviewer are the security boundary

A tool that reads your entire codebase, runs commands and reaches the network is not a neutral observer. It is the most privileged thing on your machine that day, so decide its privileges deliberately.

Claude Code’s manual mode starts read-only and asks before it edits files, runs tests or executes commands, with a built-in set of read-only commands such as ls, cat and git status allowed without prompting [1]. It can write only to the folder it was started in and that folder’s subfolders, and it asks before reading paths outside that boundary [1]. Commands that fetch content from the web, curl and wget among them, are not auto-approved by default, and you can block them outright with a deny rule [1]. The /sandbox command adds filesystem and network isolation for bash commands [1]. In auto mode a separate classifier model reviews actions in your place and blocks the ones it judges unsafe [1]. Anthropic’s own summary is the line to internalise: “Claude Code only has the permissions you grant it. You’re responsible for reviewing proposed code and commands for safety before approval” [1].

The specific hazard when the task is security review is prompt injection, because a security review reads exactly the attacker-controlled text that injection lives in: issue bodies, dependency source, test fixtures, commit messages from a fork. Claude Code fetches web content into a separate context window for this reason, and requires trust verification the first time it runs in a codebase, though that verification is disabled when running non-interactively with the -p flag [1]. The documentation is blunt about the ceiling: “no system is completely immune to all attacks” [1]. So run reviews of code you did not write inside a sandbox or a development container, with network access off, and read the diff before you approve it.

Authorization is the line, and the tool will not hold it for you

The capability now outruns the permission structure most people carry in their heads, and that is where solo operators get themselves in trouble.

Anthropic’s usage policy prohibits, in plain terms, discovering or exploiting vulnerabilities in systems, networks or applications “without authorization of the system owner” [4]. It also prohibits gaining unauthorized access through technical attacks or social engineering, and creating or distributing malware or ransomware [4]. The operative word throughout is authorization, not intent and not capability. Scanning your own repository is fine. Scanning a client’s application is fine when the client has told you in writing that you may, ideally naming the systems and the dates. Pointing an agent at a competitor’s product, a SaaS vendor you are evaluating, or a public website you happen to find interesting is not fine, and the fact that it takes forty seconds now does not change that.

The case that actually comes up is the middle one. You run a pass over your own project, and the finding is in a dependency you did not write. Do not publish it and do not open a public issue with reproduction steps. Look for the project’s security policy or SECURITY.md, report privately through whatever channel it names, and give the maintainer time to ship a fix before you say anything in public. Anthropic runs its own program on the same principle and asks finders not to disclose publicly, to report through its HackerOne program with reproduction steps, and to allow time for a fix first [1]. That is the etiquette you inherit the moment your tooling starts finding real bugs.

What still goes wrong

Finding is running ahead of fixing, and the published numbers say so. In the AI Cyber Challenge the systems discovered 86 percent of the seeded vulnerabilities and patched 68 percent of them [8]. The winning team, Team Atlanta, found 43 and patched 31 [8]. A tool that hands you 43 real problems and repairs 31 of them has still handed you 12 problems and the obligation to understand them. If your plan is to approve every suggested patch unread, you have swapped a security backlog for a correctness one, and the second is harder to notice.

Volume is the other tax. OpenAI’s own testing puts the rate at roughly 1.2 percent of commits introducing a bug [6], which sounds small until you multiply it by a year of commits and a scanner that never gets bored. Small teams abandon these tools at the triage step, not the setup step. The defence is to fix by exploitability and to accept that a long tail of low-severity findings will sit unaddressed forever, which is a decision rather than a failure.

Finally, a model review is not a threat model and not a pentest. It reads code well and reads your business badly. It will not tell you that the real risk is one contractor with a live production key, or that your backup restore has never been tested, or that the exposed endpoint nobody remembers building is the one that matters. It also cannot see the classes of flaw it was not looking for, which is precisely why the frontier capability keeps surprising the labs that build it. Use it as a fast, cheap first pass by someone tireless and slightly literal, and keep the judgment calls yourself.