Australian engineering teams have spent the last three years watching vulnerability discovery get faster while their capacity to respond stayed flat. The discovery step, scanning code for bugs, is now something Claude handles at scale. The harder problem is what follows: verifying which findings are real, triaging severity, and shipping a patch before the next sprint cycle buries it.
Anthropic's security team spent months working alongside security engineers and codified the results into a structured six-step loop. By late May 2026, Anthropic had disclosed 1,596 vulnerabilities from its own scanning of open-source software, with 97 confirmed patches in that period. The key finding: teams that built a threat model before scanning reported Claude's findings were exploitable 90 percent of the time. Teams that skipped the threat model got noisier results that slowed their patching cadence rather than accelerating it.
The six steps are not a discovery tool bolted onto a ticketing system. They are a repeating cycle the team owns, tunes, and runs on its own infrastructure.
Why the Bottleneck Shifted
A year ago the hard part was finding vulnerabilities. Static analysis tools were slow, noisy, and struggled with context: they flagged things that were not exploitable and missed things that were. Claude changed the discovery economics.
Running Claude Opus across a codebase is now fast enough that teams can parallelise scans across multiple entry points simultaneously. An Australian bank's security team running a weekend scan can cover more attack surface in 48 hours than a manual penetration test covers in a fortnight.
But discovery speed without verification capacity creates a new problem: a backlog of unconfirmed findings. Developers stop trusting the output. Severity labels become meaningless. The six-step loop solves this by making verification the designed-for bottleneck. Once the loop is running, the team knows exactly where to invest capacity.
The Six-Step Find-and-Fix Loop
Step 1: Build a Threat Model Before You Scan
The single investment that improves every other step. A threat model tells Claude what counts as a vulnerability before it starts looking. Without one, the model has detailed knowledge of the code and no knowledge of the organisation. It cannot distinguish a theoretical injection path from one that is actually reachable given the deployment context.
Building the threat model is a two-stage process. First, feed Claude these inputs:
Architecture documents, wikis, service entry points, and recent git history
Past vulnerability reports and known weak spots in the codebase
Shostack's four threat-modelling questions answered by a system owner: What are we building? What can go wrong? What are we going to do about it? Did we do a good enough job?
The output is a THREAT_MODEL.md file committed to the repository. Teams with well-documented threat models reported Claude's findings were exploitable 90 percent of the time. For Australian financial services firms operating under APRA CPS 234, the threat model also serves as documented evidence of risk identification at audit time.
Step 2: Create an Isolated Sandbox
Before running agentic scanning at scale, the team needs an environment where agents can operate safely and where exploits can be confirmed without touching production data or live accounts. This is mostly an infrastructure investment: container isolation, synthetic data, network boundaries. It pays off by making the verification step credible. A finding that cannot be reproduced in the sandbox cannot be triaged as critical.
Step 3: Run Discovery in Parallel
Discovery is the step that parallelises well. Claude reads the codebase, follows references, and looks for vulnerability patterns across the threat model's defined scope. Multiple agents can run across different modules simultaneously. The output is a list of candidate findings: not verified, not prioritised, just flagged for the next step.
First runs surface the most findings. Subsequent runs surface fewer but more complex ones. The diminishing-returns curve is expected: it means the obvious attack surface is clean, not that the tool has stopped working.
Step 4: Verify Which Findings Are Exploitable
This is the designed-for bottleneck. Not every finding Claude surfaces is exploitable in practice. Verification requires a second agent or a human reviewer to independently confirm that a path to exploitation exists in the sandbox environment, given the threat model's constraints.
Australian security teams operating under the SOCI Act for critical infrastructure need this step to produce defensible records. Confirmed findings with reproduced attack paths give the security function something it can present to a board or a regulator. Unverified scanner output does not.
Step 5: Triage and Prioritise
Verified findings get deduplicated, assigned severity, and prioritised against the threat model. A high-severity finding that requires physical access to the server room sits lower in the queue than a medium-severity finding reachable via the public API. Triage outputs feed directly into the team's sprint planning process.
Step 6: Patch, Confirm, and Scan for Variants
The final step is fixing the confirmed vulnerability, running a targeted confirmation scan to verify the fix, and then searching for structural variants. Vulnerabilities that appear in one module frequently appear in similar code elsewhere. Claude can search for variants across a large repository in minutes. A manual search across the same codebase can take days.
The Defender's Loop in Practice
Steps 3 through 6 are a repeating cycle. The threat model and sandbox are set up once and maintained on an ongoing basis. Discovery runs continuously or on a schedule. The model is stochastic: the same scan run twice will not return identical results. This is expected behaviour, not a defect. Running repeated scans surfaces different paths. A mature security program treats this as useful signal.
Anthropic's own scanning program had disclosed 1,596 vulnerabilities from open-source software by late May 2026. The disclosure and patch cadence required the full loop: discovery, verification, responsible disclosure, and confirmed patch. The loop is not a sprint-by-sprint tool. It is an operational security function that runs alongside normal engineering work.
What This Costs for Australian Engineering Teams
A structured Claude-assisted scanning program for an Australian mid-market software company at $150M to $500M revenue typically involves three cost components. Claude API costs for a monthly full-codebase scan run $800 to $2,500 AUD depending on codebase size and scan depth. Internal AppSec engineer time to build and maintain the threat model and sandbox is roughly two to four weeks upfront, then two to four hours per month. External penetration test equivalence, the work this process replaces, typically costs $45,000 to $80,000 AUD per engagement for a mid-market scope.
Teams that run the loop replace annual point-in-time penetration tests with a continuous cadence at a fraction of the per-finding cost. For APRA CPS 234-regulated firms, the documented threat model and sandbox verification records also reduce the evidence burden at audit time.
Getting Started
The two highest-value starting points are the threat model and the sandbox. A team that skips both and goes straight to discovery will get results, but they will be harder to trust and harder to act on. Start with the threat model: feed Claude the architecture documentation and wiki, interview a system owner using Shostack's four questions, and commit the THREAT_MODEL.md to the repository. That single artefact improves every subsequent step.
If your Australian engineering team wants help scoping a Claude-assisted security scanning program, including the APRA CPS 234 and SOCI Act documentation layers, book a working session.
