[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-80780":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":27,"readmeContent":28,"aiSummary":29,"trendingCount":15,"starSnapshotCount":15,"syncStatus":30,"lastSyncTime":31,"discoverSource":32},80780,"defending-code-reference-harness","anthropics\u002Fdefending-code-reference-harness","anthropics","Skills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can \u002Fcustomize","https:\u002F\u002Fclaude.com\u002Fblog\u002Fusing-llms-to-secure-source-code",null,"Python",3283,219,13,0,2165,2398,2438,6625,108.85,"Other",false,"main",true,[26],"security","2026-06-06 04:07:10","# Claude for Securing Source Code\n\nA reference implementation for autonomous vulnerability discovery and\nhuman-reviewed remediation with Claude. Not maintained and not accepting\ncontributions. For a lightweight SDK-only\nwalkthrough of the same recon → find → triage → report → patch loop, see the\n[companion cookbook](https:\u002F\u002Fplatform.claude.com\u002Fcookbook\u002Fcybersecurity\u002Fvulnerability_detection_with_claude).\n\n- **Claude Code skills**: `\u002Fquickstart`, `\u002Fthreat-model`, `\u002Fvuln-scan`,\n  `\u002Ftriage`, `\u002Fpatch`, `\u002Fcustomize`: interactive scoping, scanning, triage,\n  and patching. Open this repo in Claude Code and run `\u002Fquickstart` to get\n  oriented.\n- **`harness\u002F`**: the autonomous reference pipeline (recon → find → verify\n  → report → patch), instantiated here for C\u002FC++ memory corruption with Docker +\n  ASAN and parallel agents. A **reference, not a product**: the shape, the\n  prompts in `harness\u002Fprompts\u002F`, and the two-container trust boundary are\n  what you reuse. Run `\u002Fcustomize` to port it to your language, detector,\n  or vuln class.\n\n> ⚠️ **Security:** the interactive skills (`\u002Fquickstart`, `\u002Fthreat-model`,\n> `\u002Fvuln-scan`, `\u002Ftriage`) only read and write files and are safe as long as\n> you approve each tool use in Claude Code. `\u002Fpatch` on static findings\n> (`TRIAGE.json` \u002F `VULN-FINDINGS.json`) is likewise file-only. `\u002Fcustomize`\n> also edits pipeline source and can run validation commands. The\n> autonomous pipeline (Step 2+), including `\u002Fpatch` on pipeline results,\n> **executes target code**. It ships a gVisor agent sandbox and refuses to\n> spawn agents outside it; run `scripts\u002Fsetup_sandbox.sh` once, then invoke\n> via `bin\u002Fvp-sandboxed`. See [docs\u002Fsecurity.md](docs\u002Fsecurity.md) and\n> [docs\u002Fagent-sandbox.md](docs\u002Fagent-sandbox.md).\n\n> 🔒 **Want a managed option?** Anthropic offers\n> [Claude Security](https:\u002F\u002Fclaude.com\u002Fproduct\u002Fclaude-security), a hosted product\n> that finds and fixes vulnerabilities in your source code across multiple\n> projects. Claude Security scans your repository for vulnerabilities,\n> applies a multi-stage verification pipeline to reduce false positives, and\n> lets you manage findings through their lifecycle: triage, fix validation,\n> and rapid fix generation.\n>\n> This repository is an open-source reference implementation based on general\n> best practices for finding vulnerabilities using Claude. You can use it to\n> build your own vulnerability finding pipeline, customize the logic, and it\n> can be used with whatever access you have to Claude APIs (including\n> Bedrock, Vertex, or Azure).\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fdefending-code-reference-harness\ncd defending-code-reference-harness\nclaude\n\n> \u002Fquickstart\n# → 30-sec intro + guided first run on the canary target\n\n> \u002Fquickstart how do I port the pipeline to Java?\n> \u002Fquickstart how do I triage all these bugs?\n```\n\n## Table of contents\n\n- [**Threat model**](docs\u002Fthreat-model.md) · Decide what counts before you scan; bootstrap + interview\n- [**Prompting**](docs\u002Fprompting.md) · Task framing, scope, context, guardrails\n- [**Pipeline**](docs\u002Fpipeline.md) · How it works: diagram, stages, CLI flags\n- [**Security**](docs\u002Fsecurity.md) · Sandboxing, what not to mount\n- [**Agent sandbox**](docs\u002Fagent-sandbox.md) · gVisor isolation + egress allowlist for every agent\n- [**Customize**](docs\u002Fcustomizing.md) · Port to my stack; which files change and why\n- [**Triage**](docs\u002Ftriage.md) · How do I go through these hundreds of findings?\n- [**Patching**](docs\u002Fpatching.md) · Generate and verify fixes for verified crashes\n- [**Best practices**](docs\u002Fbest-practices.md) · 18 principles (verifier, judge, severity, variance)\n- [**Troubleshooting**](docs\u002Ftroubleshooting.md) · Duplicates, rate limits, subagent model pinning\n- [**Other uses**](docs\u002Fother-use-cases.md) · Patching, binary analysis, pentesting, bug chains\n- [**Safeguards**](https:\u002F\u002Fsupport.claude.com\u002Fen\u002Farticles\u002F14604842-real-time-cyber-safeguards-on-claude) · Block for dangerous cyber work\n\n---\n\n## Ramp-up: from scanning to patching\n\n|         |                                           |        |\n|---------|-------------------------------------------|--------|\n| **Day 1**   | Threat-model + first static scan + triage | [Step 1](#step-1-day-1-threat-model-scan-triage) |\n| **Day 2**   | Run the reference pipeline on a C\u002FC++ library | [Step 2](#step-2-day-2-run-the-autonomous-pipeline) |\n| **Day 3-5** | Customize the pipeline for your target    | [Step 3](#step-3-day-3-5-customize-for-your-target) |\n| **Week 2**  | Start autonomous scanning, triage, and patching | [Step 4](#step-4-week-2-start-scanning-triaging-and-patching) |\n\n---\n\n## Step 1 (Day 1): Threat-model, scan, triage\n\nThese skills only **read and write files** in your repo. As long as you run\nClaude Code interactively and approve each tool use, no additional sandbox\nis needed.\n\n```bash\n# One-time: pin every subagent to the model you want\nexport CLAUDE_CODE_SUBAGENT_MODEL=\u003Cmodel-id>\nclaude\n\n# 0. Front door: intro + guided first run (same as the Quickstart above)\n> \u002Fquickstart\n\n# 1. Build a threat model first (aim before you shoot)\n> \u002Fthreat-model bootstrap targets\u002Fcanary\n\n# 2. Static scan, scoped by that threat model\n> \u002Fvuln-scan targets\u002Fcanary\n\n# 3. Verify, dedupe, and rank what came back\n> \u002Ftriage targets\u002Fcanary\u002FVULN-FINDINGS.json\n\n# 4. Generate candidate fixes for the verified findings\n> \u002Fpatch .\u002FTRIAGE.json --repo targets\u002Fcanary\n```\n\nProduces `THREAT_MODEL.md`, `VULN-FINDINGS.{json,md}`, `TRIAGE.{json,md}`,\n`PATCHES\u002F`. These are **static candidates**; for execution-verified crashes,\nmove to Step 2.\n\n> **Note:** `\u002Ftriage` may mark the canary findings as false positives via its\n> \"test\u002Ffixture code\" exclusion rule, since `entry.c` self-identifies as a\n> planted-bug fixture, and that's triage working as designed. To see the\n> full confirm\u002Fdedupe\u002FFP flow, run it on the built-in fixture instead:\n> `\u002Ftriage .claude\u002Fskills\u002Ftriage\u002Ffixtures\u002Fcanary-findings.json --repo targets\u002Fcanary`,\n> or point Step 1 at your own code.\n\n→ Deeper: [docs\u002Fprompting.md](docs\u002Fprompting.md) ·\n[docs\u002Fbest-practices.md](docs\u002Fbest-practices.md)\n\n---\n\n## Step 2 (Day 2): Run the autonomous pipeline\n\nThe pipeline finds, verifies, and reports crashes autonomously, steered by\nthe focus areas from your Step-1 threat model. Under the hood it's just\n**three things**:\n\n**1. A Docker image per target.** Each target ships a `Dockerfile` that\ncompiles the code with ASAN (the crash detector). The pipeline builds this\nimage automatically on first use; you just need Docker installed and the\npipeline itself set up:\n\n```bash\npython3 -m venv .venv && .venv\u002Fbin\u002Fpip install -e .\nexport ANTHROPIC_API_KEY=sk-ant-...   # or CLAUDE_CODE_OAUTH_TOKEN; the pipeline requires one in env\n\n# The pipeline auto-builds this on first recon\u002Frun, but you can build it yourself to see what's inside:\ndocker build -t vuln-pipeline-drlibs:latest targets\u002Fdrlibs\u002F\n```\n\n**2. Recon: map before you dig.** A lightweight agent reads the source tree\ninside a network-isolated container (no execution yet) and proposes a\npartition: *\"here are 7 distinct input-parsing subsystems worth attacking\nseparately.\"* This becomes the `focus_areas` list, so parallel find-agents\neach start somewhere different instead of all piling onto the same shallow\nbug.\n\n```bash\nbin\u002Fvp-sandboxed recon drlibs --model \u003Cmodel-id>\n# → prints a focus_areas: YAML block you can paste into targets\u002Fdrlibs\u002Fconfig.yaml\n```\n\n**3. Run: the autonomous loop.** N find-agents in parallel, each in its own\nisolated container, read source → craft malformed inputs → run the ASAN\nbinary → iterate until a crash reproduces 3\u002F3. A separate grade-agent\nverifies each crash in a clean container the finder never touched, and\nexploitability reports stream out as bugs are confirmed.\n\n> ⚠️ **`run` spawns an autonomous agent.** The pipeline runs each agent\n> inside a gVisor container with egress restricted to the API; agent-spawning\n> subcommands refuse to start outside it. See\n> [docs\u002Fsecurity.md](docs\u002Fsecurity.md) and\n> [docs\u002Fagent-sandbox.md](docs\u002Fagent-sandbox.md).\n\n```bash\n.\u002Fscripts\u002Fsetup_sandbox.sh   # one-time: installs gVisor, builds agent images, verifies isolation\nbin\u002Fvp-sandboxed run drlibs --model \u003Cmodel-id> --runs 3 --parallel --stream\n```\n\nResults land in `results\u002Fdrlibs\u002F\u003Ctimestamp>\u002F`; with\n`--stream` the first report appears in minutes under `reports\u002Fbug_NN\u002F`.\n**Drive it from a Claude Code session the first time**; the repo's\n`CLAUDE.md` has per-stage guidance.\n\n→ Deeper: [docs\u002Fpipeline.md](docs\u002Fpipeline.md) (full pipeline diagram, every\nstage explained, CLI flags, rate-limit math)\n\n---\n\n## Step 3 (Day 3-5): Customize for your target\n\nThe reference pipeline is C\u002FC++\u002FASAN, but its shape is generic: *agent crafts\ninput → runs target in sandbox → detector fires → second agent verifies →\nthird writes exploitability.* Porting it means swapping a few nouns, not\nrebuilding the loop:\n\n| Axis         | C\u002FC++ demo                          | Your target (examples)                         |\n|--------------|-------------------------------------|------------------------------------------------|\n| Detector     | ASAN crash signature                | exception \u002F canary file \u002F DNS callback         |\n| PoC shape    | crashing input file                 | HTTP request sequence \u002F tx list \u002F test harness |\n| Target build | `targets\u002F*\u002FDockerfile` (clang+ASAN) | your language's build in a container           |\n\nStart by pointing the **Step-1 skills at your own code**. They're read-only,\nso you can run them immediately and see real output before touching the\npipeline. The artifacts they produce (threat model, static findings) are what\nground the `\u002Fcustomize` interview:\n\n```bash\n# Ask the front door what porting looks like for your repo\n> \u002Fquickstart how do I customize this for ~\u002Fcode\u002Fmy-service?\n\n# Build a threat model of YOUR target (reads the code, drafts, then refines it with you)\n> \u002Fthreat-model bootstrap-then-interview ~\u002Fcode\u002Fmy-service\n\n# Static scan: shows \u002Fcustomize which bug classes appear in your code\n> \u002Fvuln-scan ~\u002Fcode\u002Fmy-service\n\n# Triage the scan output: what's real, what's noise, what matters\n> \u002Ftriage ~\u002Fcode\u002Fmy-service\u002FVULN-FINDINGS.json --repo ~\u002Fcode\u002Fmy-service\n\n# Now port the pipeline, with those artifacts as context\n> \u002Fcustomize use ~\u002Fcode\u002Fmy-service\u002F{THREAT_MODEL.md,VULN-FINDINGS.json} and .\u002FTRIAGE.md\n```\n\nWhen `\u002Fcustomize` is done you'll have `targets\u002Fmy-service\u002F` wired up; validate\nit with `bin\u002Fvp-sandboxed run my-service --model \u003Cmodel-id> --runs 1` before scaling up.\n\n→ Deeper: [docs\u002Fcustomizing.md](docs\u002Fcustomizing.md)\n\n---\n\n## Step 4 (Week 2): Start scanning, triaging, and patching\n\nStep 3 left you with `targets\u002Fmy-service\u002F`: your build, your detector, your\nprompts. Run the autonomous loop on it, triage the batch, patch the top of\nthe queue, and repeat. Same ⚠️ isolation rules as Step 2.\n\n```bash\n# Scan: the autonomous pipeline, now on YOUR target (via bin\u002Fvp-sandboxed)\nbin\u002Fvp-sandboxed recon my-service --model \u003Cmodel-id>\nbin\u002Fvp-sandboxed run my-service --model \u003Cmodel-id> --runs 5 --parallel --stream\n\n# Triage: verify, dedupe, rank the batch\n> \u002Ftriage results\u002Fmy-service\u002F\u003Ctimestamp>\u002F --repo ~\u002Fcode\u002Fmy-service --auto --votes 5\n\n# Patch: static findings (no PoC), per-finding patch agent + independent reviewer\n> \u002Fpatch .\u002FTRIAGE.json --repo ~\u002Fcode\u002Fmy-service --top 5\n\n# Patch: pipeline findings (PoC + ASAN trace), delegates to the verification ladder\n> \u002Fpatch results\u002Fmy-service\u002F\u003Ctimestamp>\u002F --model \u003Cmodel-id>\n# or call the pipeline directly:\nbin\u002Fvp-sandboxed patch results\u002Fmy-service\u002F\u003Ctimestamp>\u002F --model \u003Cmodel-id>\n```\n\n`\u002Ftriage` on a pipeline batch collapses duplicates across runs, re-ranks by\nderived exploitability (not the scanner's claimed severity), and routes each\nfinding to a component owner, so engineering gets a short, ranked, owned\nlist instead of a dump.\n\n`\u002Fpatch` is the unified entry point for fix generation. On pipeline input\neach diff is graded in a fresh container by an executable ladder (apply +\nbuild, original PoC stops, regression suite still passes, fresh find-agent\nre-attacks the patched binary) and labeled `verified: \"ladder_passed\"`. On\nstatic input there is no executable oracle; diffs are reviewed by an\nindependent agent that sees only the diff and the source location, and\nlabeled `verified: \"static_review_only\"`.\n\nEither way the diff is a draft. Read it before upstreaming; see\n[docs\u002Fpatching.md](docs\u002Fpatching.md#reviewing-generated-patches) for what to\nlook for, and the same doc for porting the verification ladder to non-C\u002FC++\ntargets.\n\n→ Deeper: [docs\u002Ftriage.md](docs\u002Ftriage.md) · [docs\u002Fpatching.md](docs\u002Fpatching.md)\n\n---\n\n## Best practices\n\n**Map the system before you scan it.** On a large codebase, first have\nClaude read the whole thing and distill a system design and threat model:\nhow the components fit together, where trust boundaries sit, what's exposed.\nUse that map to prioritize which services to scan first, and run the pipeline\ncomponent-by-component. Once the individual pieces are clean, do a pass\nacross the whole system for bugs that only appear when components chain\ntogether. `\u002Fthreat-model bootstrap` is built for this first pass.\n\n**Give Claude as much context as you can.** Teams have gotten a lot of\nmileage from pointing Claude at their research docs, design docs, git\nhistory, and even internal portals alongside the code. The extra context\nlets Claude connect how components interact and what's changed over time,\nwhich is where the non-obvious bugs live.\n\n**Don't prescribe how to hunt; give context and step away.** Claude\noften finds vulnerabilities in ways a human researcher wouldn't, and that's\nfine. Long instructions, staged checklists, and piles of reference material\nusually backfire: the model pattern-matches your scaffolding instead of\nreasoning about the code. Give it the target, the goal, and the tools; let\nit choose the path.\n\n**Divide the work cleanly.** Parallel agents converge on the same shallow\nbugs unless you partition the search space first. A recon step that tells\neach agent precisely which part of the codebase to search, and what to look\nfor, is the most effective way to avoid duplication.\n\n**Invest in killing false positives fast.** The verifier is the\nload-bearing component. Layer a cheap programmatic gate\n(sanitizer signal, parse check, reproduces 3\u002F3) in front of an adversarial\ngrader agent running in a clean sandbox, and prefer executable witnesses (a\ncrash, a leaked value) over written arguments.\n\n→ Deeper: [docs\u002Fprompting.md](docs\u002Fprompting.md) · [docs\u002Fbest-practices.md](docs\u002Fbest-practices.md)\n\n## Advanced tips\n\n**Feed it your existing backlog first.** Before hunting new bugs, point the\nmodel at your current pile of open findings (older scanners, prior models,\nbug-bounty intake) and have it downgrade or disprove what it can. Teams have\ncleared hundreds of stale items this way and used the survivors to calibrate\nseverity scoring before the new findings arrived.\n\n**Give it a live sandbox, not just source.** Source plus a running\nenvironment (HTTP traffic, logs, a seeded database, an emulator) lets the\nmodel chain findings into context-aware exploits instead of stopping at\nstatic reports. The deepest results come from teams that let it execute,\nobserve, and iterate.\n\n**Expect variance; union across runs.** The same prompt on the same target\nwon't return identical findings or identical severities. Treat each run as a\nsample: run several, union the results, and don't trust any single pass.\n\n**Use a judge agent to whittle the list down.** When the pile is large, have\na second agent critique each finding and a third adjudicate between report\nand critique; the model reliably downgrades its own findings when asked\ndirectly. `\u002Ftriage` packages this loop.\n\n**Don't wait for a perfect pipeline.** Start scanning, let the model tell you\nwhat's missing, and fold the lessons back in. Teams that iterate on the\npipeline from real transcripts move faster than teams that try to design it\nright up front. A `CHEATSHEET.md` that records what worked, fed back into\nthe prompt, compounds quickly.\n\n**For open-source targets, coordinate disclosure.** Route validated\nCritical\u002FHigh findings through an OSS coordination body rather than direct\nto maintainers, and hold Low\u002FMedium; uncoordinated vuln dumps burn\nmaintainer goodwill and get ignored.\n\n","该项目是一个用于自主漏洞发现和人工审核修复的参考实现，特别针对Claude进行源代码安全加固。其核心功能包括威胁建模、扫描、分类、打补丁等，并提供了一个可自定义的自动化扫描框架。技术特点在于使用Python编写，支持交互式命令如`\u002Fquickstart`、`\u002Fthreat-model`、`\u002Fvuln-scan`等，便于用户快速上手并根据需求定制化调整。适用于需要对C\u002FC++项目中的内存损坏等问题进行安全审查与修复的场景，同时也为开发者提供了将该流程移植到其他编程语言或漏洞类型上的灵活性。通过结合Docker+ASAN以及并行代理机制，确保了高效且安全的执行环境。",2,"2026-06-06 04:03:23","CREATED_QUERY"]