Anthropic's defending-code-reference-harness: what the reference pipeline actually does
Skills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can /customize
At a glance
- What is it?
- Anthropic's defending-code-reference-harness is a Python reference implementation for autonomous vulnerability discovery and remediation with Claude. It ships Claude Code skills, a C/C++ pipeline built on Docker and ASAN, and a detection-and-response track, and it is explicitly not a product.
- Who is it for?
- Adopt it if you have a C/C++ codebase, an Anthropic API path, and an engineer willing to run /customize rather than expect an out-of-the-box scanner. Do not adopt it if you want a supported product or a pipeline you can point at Java, Go or Rust unchanged.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 42 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem it addresses: the loop around the model, not the model
Most teams that try to point a language model at a source tree end up rebuilding the same scaffolding. Prompts drift between runs. Findings arrive without evidence. Someone has to decide which of two hundred warnings is real, and nobody wrote down the severity rule. The repository is Anthropic's attempt to publish that scaffolding rather than the model itself.
The README frames it as a reference implementation for autonomous vulnerability discovery and remediation with Claude, based on partnering with security teams at several organizations. The scope is deliberately narrow: the reference pipeline under harness/ is configured for finding C/C++ memory vulnerabilities using Docker and ASAN. It is described as a reference, not a product, and the README states plainly that it will not work on every codebase out of the box.
Who it is for is equally explicit. The Ramp Up section lays out a five-step schedule, from building a threat model and running a first static scan on Day 1 to autonomous scanning, triage and patching in Week 2. That is a plan for a security engineer with a specific target, not for a team shopping for a scanner. The repository also states it is not maintained and is not accepting contributions, which changes the adoption calculus: you are forking a starting point, not joining a project.
Two tracks: preventive scanning and detection-and-response
The repository splits into two concerns, and the README is explicit that everything except the second track is preventive.
The preventive track is the Claude Code skills: /quickstart, /threat-model, /vuln-scan, /triage, /patch and /customize. These are interactive. You open the repository in Claude Code, run /quickstart to get oriented, and drive scoping, scanning, triage and patching yourself. Alongside them, harness/ holds the autonomous pipeline that runs recon, find, verify, report and patch as a sequence with no human in the loop between stages.
The detection-and-response track assumes the opposite starting condition. The README describes it as assuming an attacker is already in the logs: hunt the corpus, scope the damage, and propose a response. It consists of the /dnr-hunt and /dnr-respond skills plus dnr_harness/, with dnr-pipeline as their autonomous mirror. The demo target is targets/dnrcanary/, and docs/detection-response.md carries the detail.
That split matters when you evaluate the repository. A team looking for pre-merge static analysis gets nothing from dnr_harness/, and a team doing incident response gets nothing from the ASAN pipeline. They share a repository and a sandboxing model, not a workflow.
Installing it and running the first scan
The README's Getting Started block is short, and it assumes Claude Code is already installed and authenticated. The commands clone the repository and start Claude Code inside it.
git clone https://github.com/anthropics/defending-code-reference-harness
cd defending-code-reference-harness
claudeOnce Claude Code is running in the repository, the first real use is the /quickstart skill. The README describes it as a 30-second intro plus a guided first run on the canary target, and it accepts follow-up questions as arguments.
> /quickstart
> /quickstart how do I port the pipeline to Java?
> /quickstart how do I triage all these bugs?What you should see is a guided walkthrough rather than a scan of your own code. The canary target is the point: it lets you watch the loop end to end before you point it at anything that matters. The Ramp Up table puts a threat model and a first static scan plus triage on Day 1, and the reference pipeline on a C/C++ library on Day 2.
If you intend to run the autonomous pipelines rather than the interactive skills, there is one more step, and the README marks it clearly. The pipelines execute target code, so they refuse to run outside a gVisor sandbox unless explicitly overridden. Setup is a one-time script, and invocation goes through a wrapper rather than the bare CLI.
scripts/setup_sandbox.sh
bin/vp-sandboxedThe package itself is a normal Python project. pyproject.toml requires Python 3.11 or newer, declares pyyaml as its only runtime dependency, and exposes two console scripts: vuln-pipeline pointing at harness.cli:main and dnr-pipeline pointing at dnr_harness.cli:main. A dev extra adds pytest.
The sandbox boundary is the design decision worth studying
The security note in the README draws a line between skills that read and write files and pipelines that execute target code. /quickstart, /threat-model, /vuln-scan and /triage only read and write files. Running /patch on static findings from TRIAGE.json or VULN-FINDINGS.json is likewise read- and write-only. The README says any of these are safe to run unsandboxed as long as you review and approve each tool use in Claude Code.
That qualifier carries the weight. The skills are not sandboxed by the harness; they are bounded by the approval prompt in Claude Code. If you disable or blanket-approve tool use, the safety argument in the README no longer applies to your setup.
The autonomous pipelines are a different category. vuln-pipeline, dnr-pipeline, and /patch applied to pipeline results all execute target code, and they refuse to run outside gVisor unless explicitly overridden. The /customize skill sits in between: it edits harness code and runs validation commands, so it is not read-only either.
The detection-and-response skills add one more behavior worth noting: they run the demo app on 127.0.0.1 to verify proofs of concept. That is a local listener started by the tooling, not a remote service, but it is a process you should expect to see. docs/security.md covers what not to mount, and docs/agent-sandbox.md covers gVisor isolation plus an egress allowlist for every agent. The egress allowlist is the part I would read first, because an agent that can reach the network during a scan is a different risk profile from one that cannot.
Where the reference harness stops being useful
The README removes most of the ambiguity itself. The harness is configured for C/C++ memory vulnerabilities, using Docker and ASAN, and the README states it will not work on every codebase out of the box. If your target is a Python service, a Go binary, or a JavaScript monorepo, the autonomous pipeline as shipped is not aimed at you. The intended path is /customize, which the README describes as porting the harness to your language, detector, or vuln class.
That porting work is real work. The README says the general shape, prompts and sandboxing are reusable, which is a claim about architecture rather than about configuration. You are changing detector integration and build steps, not editing a config key.
There is a second limitation that follows from the first. Execution-verified findings depend on being able to build and run the target under ASAN inside a container. Projects with heavy native dependencies, unusual toolchains, or build systems that assume a specific host will fight the sandbox before they produce a single verified crash. The repository lists troubleshooting topics including duplicates, rate limits and subagent model pinning, which suggests the failure modes teams actually hit are operational rather than conceptual.
Finally, the maintenance position is unambiguous. The README states the repository is not maintained and is not accepting contributions. The last push was on 2026-08-06. There are no retrieved releases. Treat the code as a snapshot of a working approach, and expect to own whatever you build from it.
How it relates to Claude Security and the SDK cookbook
The README points at two adjacent options, and the difference is mostly about who operates the pipeline.
Claude Security is described as a hosted product that finds and fixes vulnerabilities in your source code across multiple projects. According to the README, it scans your repository, applies a multi-stage verification pipeline to reduce false positives, and lets you manage findings through triage, fix validation and rapid fix generation. The verification stage is the conceptual overlap with this repository: both treat a model's raw output as a candidate rather than a finding, and both add a stage that tries to confirm it. The practical difference is that with Claude Security you do not own the sandbox, the prompts or the detector configuration, and you cannot change them.
The second alternative is the companion cookbook, linked from the README as a lightweight SDK-only walkthrough of the same recon, find, triage, report and patch loop. That is the right comparison if you want to understand the loop without adopting the repository's structure. The cookbook is a walkthrough; this repository is a runnable harness with skills, a sandboxed pipeline, demo targets and documentation. If you are evaluating whether the approach works at all, the cookbook is the smaller commitment. If you need something you can run against a target tonight, the harness is the one with the CLI.
A third path the README mentions is access: the repository can be used with whatever access you have to Claude APIs, including Bedrock, Vertex or Azure. That is a deployment consideration rather than a functional one, but it decides whether the harness fits your existing cloud posture.
Licence, upgrade cost and what you are actually taking on
The repository's licence field resolves to NOASSERTION, and the LICENSE file is not reproduced in the repository files I can inspect here. That means the terms are not something I can summarize, and the safe reading is that you check LICENSE directly before you build anything on top of it. If you plan to redistribute a modified harness or ship it inside a product, the licence is the first file to open, not the last.
Upgrade cost is unusually simple, because there is nothing to upgrade to. The README states the repository is not maintained and is not accepting contributions, and the last push was on 2026-08-06. There are no retrieved releases. You will not be pulling fixes.
The dependency surface is small, which limits how much rot you inherit. pyproject.toml requires Python 3.11 or newer and lists a single runtime dependency, pyyaml, with pytest as a dev extra. The heavier requirements are environmental rather than packaged: Docker, ASAN, and gVisor for the autonomous pipelines. Those are the components most likely to break under you, and none of them are pinned by the project.
One practical consequence: because the pipelines refuse to run outside gVisor unless explicitly overridden, an upgrade to your container runtime or to gVisor itself can stop the pipeline before any Python code runs. Keep scripts/setup_sandbox.sh in your own test loop rather than treating it as a one-time bootstrap.
Editorial conclusion
Adopt it if you have a C/C++ codebase, an Anthropic API path, and an engineer willing to run /customize rather than expect an out-of-the-box scanner. Do not adopt it if you want a supported product or a pipeline you can point at Java, Go or Rust unchanged. Verify two things before committing: that scripts/setup_sandbox.sh produces a working gVisor sandbox on your host, and that the ASAN build of your target actually runs inside it, because the harness is documented as a C/C++ memory-safety reference and the README states it will not work on every codebase out of the box.
Frequently asked questions
What is threat modeling as code?
In this repository it is the /threat-model skill, one of the Claude Code skills listed in the README alongside /quickstart, /vuln-scan, /triage and /patch. The README's Ramp Up plan puts building a threat model on Day 1, and docs/threat-model.md explains why a threat model cuts false positives. The threat model is written into the repository as a file the later skills read, which is what makes it code rather than a document.
Which framework can be used in threat modeling to identify potential threats?
The README does not name a threat modeling framework. The repository provides its own /threat-model skill and points to docs/threat-model.md for the reasoning behind it, but no external framework is identified in the README or pyproject.toml.
Does the defending-code-reference-harness work on languages other than C and C++?
Not as shipped. The README states the harness under harness/ is configured for finding C/C++ memory vulnerabilities using Docker and ASAN, and that it will not work on every codebase out of the box. Porting it is the job of the /customize skill, which the README describes as porting the harness to your language, detector, or vuln class.
Why does the defending-code-reference-harness refuse to run outside a sandbox?
Because the autonomous pipelines execute target code. The README states that vuln-pipeline, dnr-pipeline and /patch applied to pipeline results refuse to run outside a gVisor sandbox unless explicitly overridden, and that setup is a one-time run of scripts/setup_sandbox.sh followed by invoking the pipeline through bin/vp-sandboxed.
Is the defending-code-reference-harness still maintained?
No. The README states the repository is not maintained and is not accepting contributions, and the last push was on 2026-08-06. The README also points readers who want a managed option to Claude Security.
Community notes