Frontier models can now find and fix real vulnerabilities at a much larger scale, so scanning is no longer the main constraint.
2
A useful security workflow separates discovery, verification, triage, and patching, with a threat model and isolated sandbox prepared first.
3
Teams should start hands-on with open source dependencies, learn where models lack context, and keep a human involved before automating patches.
Summary
Eugene Yan describes how Anthropic has worked with security teams to find and fix vulnerabilities in source code. He argues that models have improved enough to find real bugs at scale, citing Mozilla Firefox's jump from roughly 20 monthly fixes to 400 in April 2025 and Anthropic's scan of more than a thousand open source repositories. The difficult work has moved to verification, triage, and patching. His six-step workflow starts with a written threat model and a reproducible sandbox. Discovery aims for recall, while an independent verification agent aims for precision by trying the exploit in a fresh container. Triage ranks issues against business context and engineer attention. Patching includes reattacking the fixed code and keeping tests green. Yan is direct about the organizational limits: severity rules, routing, and patch review do not scale automatically. He recommends starting interactively with open source dependencies before building a larger harness.
Model security capability has jumped enough to produce real vulnerability fixes
Yan uses cybersecurity time-horizon benchmarks to show that models are completing longer tasks such as identifying and exploiting weaknesses, reverse engineering, and web exploitation. He says the capability curve shows a step jump over the earlier regression line. Mozilla Firefox's monthly security fixes illustrate what that change buys defenders. The average in 2025 was about 20 fixes, then the count reached about 60 and 70 in February and March, before reaching 400 in April. Mozilla attributed about two thirds of the April fixes, roughly 271, to a frontier model. Yan's point is that models can now help defenders find and fix vulnerabilities at scale.
The bottleneck has moved from finding bugs to proving, ranking, and fixing them
Anthropic scanned more than a thousand open source repositories. Of 23,000 candidates, 6,200 were rated high or critical, 1,600 were reported to maintainers, and about 100 were patched upstream at the time of the update. Yan says finding vulnerabilities is now fairly straightforward. The harder work is verification, triage, and patching. Earlier automated experiments produced too many false positives to scale. Agentic harnesses changed that by giving models ways to inspect systems, run tests, and dismiss speculation that cannot be reproduced. The model and the harness need to work together because reading source code alone does not establish that an issue is exploitable.
A written threat model gives the model system context that source code cannot provide
Yan says teams have found that a well-documented threat model can raise the true positive rate to 90 percent. A model has strong context about code it can read, but weak context about why the system was designed a certain way, what on-call engineers have been fixing informally, and which compensating controls exist. He recommends bootstrapping the document from code, system documents, old commits, patches, and CVEs, then having the model interview a system expert. In the order service example, the threat model records customer PII as the asset, the orders API as the entry point, and possible threats such as SQL injection and unauthenticated access.
The sandbox must isolate exploit attempts and give every agent the same starting point
The workflow runs untrusted code and deliberately detonates proof-of-concept exploits, so Yan recommends a virtual machine with no egress and no cloud credentials. Reproducibility matters as well. Agents should start from the same baseline container, especially when a finding depends on an old dependency or a particular system state. Yan describes an order-service test bed made from three Docker images, one for the application, one for the Postgres database, and one for the Redis cache. A security agent sits outside the target boundary and probes the application over HTTP. Teams told him that live test beds where agents can run exploits were their biggest lever.
Discovery improves when models receive context, simpler prompts, and tools
Yan recommends giving the discovery agent as much written context as possible, then using simpler prompts as models improve. Instead of listing every vulnerability class, a newer model may only need an instruction to look for untrusted data crossing a trust boundary. Tools matter because a security engineer does more than read source. One pentesting team gave its model tools to query an API, inspect responses, read logs, and read source code. Its true positive rate became almost 100 percent because the model could verify findings during the process. In the running example, the agent spots a five-line order lookup where Python string interpolation places user input directly into a SQL query, allowing data exfiltration.
Independent adversarial verification protects recall and reduces false positives
Yan separates discovery from verification because they optimize different goals. Discovery aims for recall by finding as many possible vulnerabilities as possible. Verification aims for precision by testing which findings are truly exploitable. If the discovery agent debates its own work, it may censor itself and miss issues. The verification agent should therefore be independent and adversarial. It receives the suspected vulnerability without the discovery agent's reasoning traces, assumes the claim may be false, and tries to disprove or confirm it. In the order-service example, it receives the relevant line, runs a curl request in a fresh container, and observes customer PII being exfiltrated.
Triage must spend scarce engineer attention on issues with real business impact
A true finding may still have low business impact, and sending engineers every confirmed issue can damage their trust in the security process. Yan calls engineer attention the scarce resource. Triage can deduplicate findings, cluster related issues, and rank them by impact and likelihood. The threat model supplies the business context. An SQL injection might be downgraded when an application firewall blocks it and the service is internal-only. A database containing customer PII or healthcare data might make an issue more severe than the code alone suggests. In the example, an agent rates the issue high, while human review lowers its likelihood because of the firewall and internal deployment.
Patching closes the loop when the exploit stops, tests stay green, and a new scan passes
Yan describes a validation ladder for patches. First, the original proof of concept must stop working. The existing test suite must remain green so the patch does not introduce a regression. Then a fresh discovery agent should attack the patched code again to test whether the fix is complete. In the order service, the fix moves the variable out of Python string interpolation. The team also records the application firewall and internal-only deployment as explicit compensating controls. Yan says feedback improves patch quality. Each scan should make the harness better by preserving what the team learned, turning repeated operational work into an accumulating asset.
The workflow looks like a machine learning pipeline, but organizational limits are harder
Yan summarizes the technical workflow as context, isolation and reproducibility, recall, precision, ranking, and closing the loop. He compares the later stages to a machine learning pipeline: discovery optimizes recall, verification optimizes precision, triage ranks results, and patching feeds new information back into the system. The harder problems appear when the volume of findings grows. Compute and engineering work can be increased with money, but human attention cannot scale in the same way. Product and security engineers need written agreement about what high and critical severity mean. Teams also need rules for routing findings to code or service owners, plus enough bandwidth for humans to review generated security patches.
"Scanning is not the bottleneck. Verification, triage, and patching. And then all your organizational processes. Those are the bottleneck."20:39
Who should watch
You maintain source code or open source dependencies and want to use models for vulnerability discovery without handing them unchecked access to production systems.
Your security scanners produce more findings than engineers can verify, rank, and patch, and you need a workflow that protects developer attention.
You are building an agentic security harness and need practical guidance on threat models, sandboxing, adversarial verification, and patch validation.
