Anthropicが公開したDefending Code Reference Harnessは、Claudeで脆弱性発見から修正候補作成までを回す参照実装です。公式READMEでは「reference, not a product」と明記されており、そのまま全社導入する製品ではなく、自社の検査パイプラインを組む際のたたき台という位置づけです。
実務上のポイントは、threat modelからtriage、patchまでの流れが分断されていないこと、対話的に試すスキル群と自律ハーネスが分かれていること、危険な部分だけをgVisor sandboxに閉じ込める前提で設計されていることです。PoCとして試す価値は高い一方で、未保守リポジトリであり、C/C++のメモリ脆弱性向けに最適化されている点は先に理解しておく必要があります。
Defending Code Reference Harnessで何ができる？
公式READMEによると、リポジトリには2系統の機能があります。1つはClaude Code上で動かす /quickstart、/threat-model、/vuln-scan、/triage、/patch、/customize といった対話型スキルです。もう1つは harness/ 以下の自律パイプラインで、recon、find、verify、report、patch を段階的に実行します。前者は人が途中で確認しながら進める使い方、後者は複数エージェントで発見ループを回す使い方と考えると整理しやすいです。
特に自律パイプラインは、BuildでASAN付きイメージを作り、Reconで攻撃面を分割し、Findで異常入力を作り、Verifyで別エージェントが再現確認し、JudgeやDedupeで重複を避け、Reportで構造化レポートを書き、最後にPatchで修正候補を検証する構成です。単発の静的解析ではなく、再現性のあるクラッシュと証跡を積み上げる前提なので、AppSecチームがレビューしやすい形に寄せられています。
最初に理解したい前提: 製品ではなく参照実装
このリポジトリは「not maintained and is not accepting contributions」と明記されています。運用中の商用製品を期待して入れるとズレます。公式が勧めているのは、まずDay 1で threat model と static scan、triage を回し、Day 2で既知のC/C++ライブラリに対して reference pipeline を動かし、Days 3-5で自社向けに customize する段階導入です。いきなり本番コードに広げるより、小さく検証してから対象言語や検査対象を絞り込むほうが現実的です。
READMEではAnthropic直結だけでなく、Bedrock、Vertex、Azureでも使えると説明されています。価値の中心は脆弱性探索の工程設計です。
threat model と triage が先にあるのが強み
Anthropicのcookbookでは、まずTHREAT_MODEL.mdを作り、そこからfind loopに入る流れを強調しています。これは「とりあえず大量に回して後で考える」方式より、どの入力経路が危ないか、どの資産が守るべき対象かを先に定義する考え方です。false positiveが多い静的解析でも、triageで再現性や到達性を見直す段を挟めるため、レビュー対象を絞りやすくなります。
実務では「何件見つかったか」より、「何件を再現できたか」「既知バグと重複していないか」「どの修正候補まで用意できたか」が重要です。reference harnessは、findの推論とgraderの再検証を分離し、PoCだけを受け渡す構造で、監査しやすさを優先した設計です。
sandbox運用で確認したい4つのチェックポイント
公式security.mdの要点は明快です。自律パイプラインは target code を実行するため、bin/vp-sandboxed で起動し、各エージェントを gVisor container に閉じ込め、API以外へのegressを制限する前提です。チェックポイントは4つあります。① credential-bearing paths を絶対に mount しない、② plain Docker や --privileged で回さない、③ setup phase で依存取得を済ませて attack phase には外向き通信を持ち込まない、④ patch agent の差分は必ず人が確認する、の4点です。
特に見落としやすいのは、対話型スキルと自律パイプラインで必要な隔離レベルが違うことです。READMEでは /threat-model、/vuln-scan、/triage は read/write 中心なので、Claude Codeで承認を挟めば unsandboxed でも扱えます。一方で run や pipeline result に対する /patch は別で、ここは実行を伴うので強い隔離が必要です。全部まとめて危険扱いするのでも、全部同じ感覚で許可するのでもなく、段階ごとに権限を切る設計が必要です。
導入判断: どんなチームに向く？
向いているのは、C/C++資産があり、ASAN付きビルドやDockerベースの検証を回せるAppSecチームです。threat modelやtriageをドキュメントとして残し、PoC再現や修正レビューまで分業したい組織と相性が良いです。逆に、完成済みSAST製品のような体験を求める企業には、そのままでは重い可能性があります。READMEでも、管理された選択肢としてClaude Securityを別に案内しています。
判断軸は、「社内で検査パイプラインを育てたいか」「危険作業を隔離する基盤を持つか」「未保守の参照実装を自前で変えられるか」の3つです。本番では、自社標準に合わせて薄く取り込むほうが安全です。
FAQ
Q. すぐに全言語へ横展開できますか？ A. 公式では harness が C/C++ の memory vulnerabilities を前提にしており、/customize で自社の language、detector、vuln class に移植する想定です。最初から万能ではありません。
Q. unsandboxed で回してよいですか？ A. 対話型の read/write 中心スキルは人の承認を前提に許容されていますが、自律パイプラインは不可です。公式は gVisor と egress 制限を必須前提にしています。
Q. すでに完成品が欲しい場合は？ A. READMEでは managed option として Claude Security が案内されています。参照実装を自前運用したいのか、運用込みで任せたいのかを先に分けるべきです。
AIエージェントの検証基盤や、脆弱性探索の承認フローを整えたい場合は、 HelloCraftAIへ相談してください 。sandbox方針、評価観点、レビュー導線まで含めて導入前提を整理できます。
