Anthropic just open-sourced their vulnerability discovery framework with a striking claim: “Discovery is now straightforward to parallelize, and the bottleneck has shifted to verification, triage, and patching.”

This isn’t theoretical. They’ve been working with security teams to find and fix vulnerabilities in their own code and open source software. As of May 22, 2026, they’d disclosed 1,596 vulnerabilities through their scanning. 97 had been patched. That 6% patch rate tells you where the bottleneck is. (Caveat: this is a snapshot — some findings may have disclosure lag, some could be duplicates across projects, others may be awaiting third-party fixes. The gap is still real.)

The framework they’re releasing isn’t a polished product — it’s a reference implementation with the warning “will not work on every codebase out of the box.” But the general shape, prompts, and sandboxing patterns are the distilled learnings from those partnerships. And critically, they’re releasing Claude Code skills (/quickstart, /threat-model, /vuln-scan, /triage, /patch) so you can interact with the framework step-by-step instead of running it blind.

The Loop: Threat Model → Sandbox → Discover → Verify → Triage → Patch

The first two steps are setup. The last four are the loop you run repeatedly.

1. Threat Model: Define What Counts Before You Start

The most common cause of false positives is that the model lacks understanding of your trust boundaries.

One team’s assessment: findings “were exploitable 90 percent of the time” when they had well-documented threat models, system design docs, requirements, and constraints. When those were missing, the model flagged unexploitable code because it guessed wrong about what was trusted.

The bootstrap: Feed Claude what you’d give a new security engineer on day one — architecture docs, wikis, entry points, git history, and past vulnerabilities. Ask it to create a threat model: system context, assets, entry points, trust boundaries, and vulnerability classes clustered from past bugs. Make sure the model documents what you don’t care about and why.

The interview: Have Claude interview someone who knows the system well using Shostack’s four questions: What are we building? What can go wrong? What are we doing about it? Did we do a good job? The bootstrap gives them a draft to refine, not a blank slate.

One team reviewed hundreds of past CVE and security-fix commits, distilled them into “bug-shape” hints, and asked Claude two questions: was the fix complete, and was it applied everywhere else? They found three exploitable issues in an hour. Their insight: “‘What have people exploited in the past’ is sometimes a much easier cheat-code towards success than ‘find me vulnerabilities in this codebase.’”

Why this matters: Another team had a 40% false positive rate. The findings were reproducible, the PoCs proved exploitability. But the dev team dismissed them because the bugs didn’t fit the project’s threat model. One CISO put it succinctly: “[The model has] good context of the code, but not good context of us.”

Output: A THREAT_MODEL.md file checked into the repo. The discovery agent reads it before scanning. Update it when the code changes. (For public repos: consider whether detailed threat models, trust boundaries, and past bug classes could aid attackers — some teams keep these in private wikis instead.)

2. Sandbox: Run Agents Safely and Prove Exploitability

Two purposes:

1. Protect your systems. One team told the model it had no network access when it actually did — the model discovered it could fetch from GitHub anyway. Another team’s agent answered a GitHub issue mid-scan. Neither was malicious, but both showed you need to enforce constraints via code, not just prompts.

2. Prove exploitability. During static scanning, the model reads code and hypothesizes. It can’t test if a path is reachable or if there’s a compensating control. When teams built sandboxes where the agent could compile, run tests, and detonate a proof of concept, non-exploitable findings dropped significantly.

One offensive-security team’s rule: “It’s only a true positive if the agent can build a proof of concept and run it on the test bed.” Their assessment after six weeks: “The biggest efficacy lever has been giving the model test beds, live systems, and running the PoCs.”

Isolation architecture:

• Containers are fine for the discovery agent reading code.
• MicroVMs (Firecracker) or full VMs with egress locked down for running the target and PoCs.
• Never have credentials (~/.aws, ~/.ssh, .env) available to the agent.
• Network access only during setup. Pull dependencies, build, install tools, deploy the target, run existing tests. Then snapshot the environment and remove network access. During scanning, allow traffic only to the model API, routed through a local proxy. (For regulated codebases: even API-only egress may leak source excerpts and traces in model context — review your data residency requirements.)

Pin everything: image tags, commit SHAs, dependencies, build commands. One team’s scan flagged a vulnerability that turned out to be the agent downloading an older library version instead of what was deployed. They now build Docker containers with dependencies pinned to match production.

Trade-off: If building a representative sandbox is impractical (cloud dependencies, data stores, etc.), start with discovery anyway. Frontier models are good at finding vulnerabilities from static analysis. The cost is more time in verification without PoC evidence. You can build the sandbox later once findings justify it.

Reference implementation: Anthropic’s harness uses gVisor-isolated containers with egress locked to the model API. Target is built from a Dockerfile pinned to a specific commit.

3. Discovery: Rich Context, Short Prompts, Useful Tools

Counterintuitive finding: More prescriptive prompts make discovery worse. Long checklists reduce the model’s creativity and generate fewer novel bugs.

What works:

• Goal and context, not checklists. Tell the model why you’re scanning and what a finding looks like. Leave how to the model.
• Ask for specific vulnerability classes. If you want to focus (guided by prior CVEs or language), describe the class — what it does, where it tends to live — so the model recognizes it in your codebase.
• Define structured output. Ask for a report with predefined fields (rationale, finding, impact, severity). Order them so the model’s reasoning builds on each field. Include an escape hatch so weak findings exit early.

Give the model tools: grep, glob, SAST scanners, fuzzers. Ask what tools it needs for a specific task. Let it write tools as needed — recent frontier models are increasingly good at that. (Guardrail: review or whitelist agent-authored tools before execution; letting the agent expand its own execution surface unreviewed adds risk.)

One pentesting team gave the discovery agent tools to send requests, check responses, and query traffic logs. The agent didn’t need to guess if a path was reachable — it tested each candidate against the running application as it went. True-positive rate: nearly 100 percent. (Sample size and scope not disclosed — your mileage may vary with less instrumented sandboxes.)

Parallelization pattern:

1. First pass: partition the search space (by attack surface, endpoint, component)
2. Parallel discovery agents on each partition (they don’t converge on the same shallow bugs)
3. System-level pass that takes partition-level findings as context to search for integration vulnerabilities

Teams that tried to brute-force discovery by throwing more agents at the problem hit diminishing returns. One team: “We initially tried to just horizontally scale and send more agents, but saw limiting returns.” Another increased parallel agents and got “tons of issues” — most duplicates of each other.

Output: Structured finding reports. If you have a sandbox, ask the agent to build a PoC (script, crashing input, failing test). Even if the agent can’t reproduce it, flag it as unproven and report it — keep recall high. (Trade-off: unreproduced findings create verification backlog; if alert fatigue sets in, tighten the confidence threshold.)

4. Verification: Independent Confirmation Before You Act

The agent that discovered a finding is anchored to that hypothesis. Verification must be independent.

How to verify:

• If the finding has a PoC, run it in the sandbox. Does it actually crash, exfiltrate, or bypass the control?
• If no PoC, have a different agent analyze the finding with fresh context. Does it agree?
• Check for compensating controls in production (WAF, auth gateway, network segmentation) that make the finding unexploitable in your environment.

Where to invest verification effort: The distribution of findings is typically long-tailed. A small number of critical bugs matter a lot; most findings are low-severity or non-exploitable given your threat model. Triage by impact first (next step), then verify the critical ones deeply.

5. Triage: Deduplicate, Calibrate Severity, Prioritize

Findings from parallel agents will have duplicates. Use the threat model to dedupe and calibrate severity to your system.

One team’s pattern: cluster findings by root cause, pick a representative from each cluster, verify the representative, then batch-fix the cluster. This avoids verifying the same bug five times because five different endpoints trigger it.

Severity calibration: A bug that’s critical in one system may be low-severity in another. Example: a TOCTOU race in a config parser. If the config is trusted (loaded once at startup from a file owned by root), it’s not exploitable. If the config is user-provided (uploaded via API), it’s critical. The model can’t know this without your threat model.

Output: A deduplicated, severity-calibrated list of findings prioritized by risk. This is what you hand to developers to fix.

6. Patching: Apply, Verify, Search for Variants

Three steps:

1. Generate the fix. Have Claude propose a patch. If you have a sandbox, have it write tests that prove the vulnerability, apply the patch, and confirm the tests pass.
2. Verify the fix. Run the original PoC. Does it still work? If yes, the fix is incomplete. Iterate.
3. Search for variants. The bug you just fixed likely has siblings. Have Claude search the codebase for the same pattern elsewhere and propose fixes for those too.

One team’s finding from CVE analysis: many security fixes were incomplete or not applied everywhere. The model is good at “find this pattern elsewhere” when you give it a concrete example.

Output: Merged patches. Updated tests. A record of what was fixed and where it was applied.

---

The Bottleneck

Anthropic’s data: 1,596 disclosed vulnerabilities, 97 patched. That’s not a model capability problem — it’s a people and process problem. Finding vulnerabilities at scale is easy now. Verifying them, prioritizing them, and actually shipping the fixes is hard.

The teams that found and fixed the most converged on this loop because it matches how security teams already work — just with the model doing the repetitive, parallelizable parts (scanning, clustering, variant search) and humans doing the parts that require judgment (threat modeling, severity calibration, risk prioritization).

What’s Different from Traditional SAST

1. Context-aware. The model reads your threat model, architecture docs, and past bugs. Traditional SAST doesn’t.
2. Creative. The model finds novel bug classes, not just pattern-matched signatures. Traditional SAST is bounded by its rule set.
3. Interactive. You can ask Claude “why is this exploitable?” or “find variants of this bug” mid-scan. Traditional SAST dumps a report and exits.
4. Bottleneck-aware. The framework explicitly separates discovery (fast, parallel) from verification and triage (slow, judgment-heavy). Traditional SAST conflates them.

The trade-off: nondeterminism. The same scan on the same codebase will find different bugs each time. Traditional SAST is deterministic. You need to run the loop multiple times on a codebase’s first iteration and decide when to stop based on diminishing returns and your risk tolerance.

Practical Takeaways

1. Threat model first. If you skip this, expect 40% false positives because the model guessed wrong about what you trust. Budget a day to bootstrap the threat model from docs and CVEs, then have Claude interview a system owner to refine it.

2. Sandbox setup is a one-time investment (with ongoing maintenance). Build it once per codebase, snapshot it, reuse it for every scan. The payoff is proving exploitability and reducing false positives. But snapshots drift as dependencies, configs, and infra change — plan to refresh the sandbox periodically to match production. If building it is impractical, start with static scanning anyway — just budget more verification time.

3. Discovery is cheap. Verification, triage, and patching are expensive. Parallelize discovery aggressively. Be selective about parallelizing verification — duplicate findings waste compute, so cluster before verifying. The exception is high-severity findings, where independent parallel verification reduces anchoring and speeds incident response. Triage by impact first, verify critical findings deeply (in parallel when speed matters), batch-fix clusters.

4. Use the model to search for variants after you patch. This is where LLMs shine. Give Claude a fixed bug and ask “where else does this pattern exist?” It’s fast at this and reduces the “incomplete fix” problem.

5. Iterate the loop. First run on a codebase will find the most bugs. Subsequent runs find fewer but often more complex bugs. Don’t expect the nth run to have zero findings — models are stochastic, and large codebases have long tails.

6. Start with the open-source harness. Even if you can’t use it directly (different language, different vulnerability classes), the general structure (partition → parallel scan → verify independently → triage by threat model → patch + variant search) is reusable. The Claude Code skills (/quickstart, /threat-model, /vuln-scan, /triage, /patch) let you step through the loop interactively before automating.

---

If your threat model includes “can an attacker exploit our code faster than we can patch it,” the answer may be shifting. Anthropic’s 1,596 disclosures with 97 patches isn’t a criticism of patch velocity — it’s a demonstration that discovery scaled faster than everything else in their partnerships. The framework they’re releasing is the pattern that worked for the teams who closed that gap. Whether this generalizes depends on your codebase maturity, threat model scope, and verification capacity.

The repo is on GitHub. The blog post has more detail on each step. If you’re building AI-powered security tooling, this is the reference architecture.

Sources:

• “Using LLMs to secure source code” — Anthropic Blog (June 2026)
• “Defending Code Reference Harness” — GitHub: anthropics/defending-code-reference-harness
• “Glasswing: Collaborating with security teams” — Anthropic