Defending Code Reference Harness - AIベースの脆弱性発見と修正のためのAnthropicオープンソースフレームワーク
(github.com/anthropics)- Defending Code Reference Harnessは、Claudeで自律的な脆弱性発見と修正を行うための参照実装であり、複数組織のセキュリティチームとの協業で得た知見をもとに構成されたプロジェクト
- このリポジトリは製品ではなく参照実装であり、現在はメンテナンスされておらず、コントリビューションも受け付けていない
- Anthropicはマネージドな代替としてClaude Securityを提供しており、複数プロジェクトのソースコードから脆弱性を見つけて修正し、triage、fix validation、rapid fix generationのライフサイクルを管理できる
- Claude Code向けskillsとして
/quickstart、/threat-model、/vuln-scan、/triage、/patch、/customizeを提供し、対話的なスコープ設定、スキャン、triage、パッチ作業を支援する harness/はrecon → find → verify → report → patchフローの自律参照パイプラインであり、DockerとASANを使ってC/C++のメモリ脆弱性探索向けに調整されている- 参照パイプラインの一般構造、プロンプト、サンドボックス方式は再利用できるが、すべてのコードベースでそのまま動作するわけではなく、
/customizeで言語、検出器、脆弱性の種類に合わせて移植する必要がある /quickstart、/threat-model、/vuln-scan、/triageと静的結果に対する/patchは、ファイルの読み書きのみを行い、Claude Codeで各ツール使用を確認・承認すればサンドボックスなしで実行できる- 自律参照パイプラインとパイプライン結果に対する
/patchは対象コードを実行するため、明示的に回避しない限りgVisorサンドボックス外での実行を拒否する - パイプライン実行には
scripts/setup_sandbox.shでgVisorとエージェントイメージを準備する必要があり、DockerとANTHROPIC_API_KEYまたはCLAUDE_CODE_OAUTH_TOKEN環境変数が必要 - 実行段階はbuild、recon、find、verify、dedupe、report、patchに分かれ、findエージェントは隔離コンテナ内でmalformed inputを生成し、ASANバイナリが3回中3回クラッシュするまで探索する
- verify段階では別のgraderエージェントが新しいコンテナ内でproof of conceptだけを受け取り、クラッシュを再現し、dedupe段階では新しいバグ・既存バグのより良い例・重複かどうかを判定する
- report段階ではprimitive class、reachability、escalation path、severityを含む構造化されたexploitability analysisを作成し、patch段階では修正案を作ったうえで、ビルド、元のproof of conceptでクラッシュしないこと、テスト通過、回避可能性の再探索を確認する
- 初期利用フローは、Day 1でthreat modelと静的scan・triage・candidate patchを作成し、Day 2でC/C++ライブラリで実行検証済みのfindingsを生成し、Days 3-5で自前の対象向け
targets/<your-service>/を作る流れ - 独自スタックへ移植する際は、findingシグナル、proof of conceptの形式、ビルド・実行方式を定義する必要があり、C/C++参照はASAN crash signature、crashing input file、clang+ASANベースのDockerfileを基準にしている
- 自律triageとpatchingはまだ未解決の課題であり、
/patchの検証戦略が基準を引き上げる一方、severityと優先順位は環境ごとの判断であり、検証済みパッチが常にupstream可能とは限らないという制約がある
1件のコメント
Hacker Newsのコメント
こういうのは 作業場の治具 に近い。欲しければクロスカットスレッドを買うこともできるが、木工をやる人の多くは自分で作って使う。
2年前は自分のハーネスを作るコストが高かったので事情が違ったが、今はこういうものは発想の参考として見て、自分の作業スタイル、インターフェース、対象とする範囲や工数の定義、通知方法に合わせて自作するのが最善に思える
AI以前は、自分の問題を解くソフトウェアを作るのに人手のコストが大きかったので、他人にも再利用できるよう一般化する追加の手間をかけることがよくあった。今ではほとんど手間がかからないので、ソフトウェアは一般化されないままに残る。
最近は自分の作ったものをほとんど共有していない[0]。他人の役に立つ可能性があまりなく、似たものが必要なら私のものを拡張したり直したりするより、自分にぴったり合うものを作れるからだ。治具のように。
0: https://redfloatplane.lol/blog/17-why-share/ および関連記事
私たちの生活では 目的特化ツール を作るほうがよい場面が多く、モデルが新しく出るたびにそうしたツールの複雑さも増していく。
こういうものは本当に個人用ツールだ。他の人も持ちうる問題を解くが、その人自身の作業スタイルに強く結びついているので、他人に説明したり適応させたりするのが難しい。だから作業場の治具なのだ。
私もこうしたカスタムスクリプトやプログラムを10個くらい持っているが、こういう感覚は大学以来初めてだ。当時は設定を好きなだけカスタマイズする時間があり、今は エージェント がある。
友人たちに見せたい気持ちはあるが、実際にどう説明するか頭の中でたどってみると、彼らは多くの癖を理解できないだろうと思う。それは私自身の癖だからだ。私の問題を非常によく解く、かなり複雑な技術の断片であり、その問題はより大きな問題の個人的な変形で、少なくとも今のところ私がサポートするつもりはない。
私たちがこの方向に進んでいるのはあまりにも明らかなのに、いまだに多くの人はコードはエリートのものだと信じている。プロダクト用コードはそうかもしれないが、それ以外では、じきに親のコンピュータでさえ自分のために自分で書いたコードを実行するようになる気がする。セキュリティ面では怖いが、考えると面白い
しかも自分でやっても、私が数か月かけて磨いたAIワークフローは ultracode のせいですぐ時代遅れになってしまった
多くの組織では、こうした仕事を担当するチームのところに来る利用者がますます減っているのではないかと思う
自分で作るコストはあまりにも安く、他人の基本構成要素に縛られるコストはあまりにも高い。
ただし、AIコーディングを既存ツールにグラウンディングするのはとてつもなく強力だ
これを実行するのにどれくらい費用がかかるのか気になる。
https://github.com/anthropics/defending-code-reference-harne... によると:
もしかすると1桁台の倍率差になるかもしれない
この計算機を見ると、開発者100人の会社が年間トークン費用で約 250万ドル に達しうるので、かなり衝撃的だ。
https://ai-cost-calculator.arnica.io
ただ、API で回すとコストは急速に膨らみそうだ
推定なので外れる可能性はあるが、私たちの経験を基に大まかなレンジを示している。フィードバックをもらえるとうれしい
ただ、もっと大きい数字で見ても、この種のツールが狙う発見のための正式なセキュリティ契約費用の約10分の1かもしれない。PR レビューや
/security-reviewだけでは出てこず、専門家がオープンソースフレームワークの事前作業を主導して初めて得られる類いの結果だ。そうした契約をどう進めるか見極める時間や遅延は計算にすら入れていない。率直に言えば、重要なものなら、単一スキャンに1か月分のバイブコーディング予算がかかったとしても、「1ドルあたり数セント」レベルで非常に安い。
同時に、その結果には依然として専門家が必要だ。提案が役立つこともあれば、積極的に有害なこともありうるし、事前作業の品質次第でもある。
IT部門長には、数千ドルを使ってこれを回し、恐ろしい結果ページで予算を確保したうえで、脆弱性を見つけて分類し、必要なら修正まで手伝い、社内チームを セキュリティ志向 に訓練できるレッドチームと関係を作ることを勧めたい
「このリポジトリは保守されておらず、コントリビューションも受け付けていません。」
ふむ :)
https://github.com/space-bacon/SRT
一晩で全固定モデルを大きく改善できる。行こう
良いハーネスがないと、codex/claude から得られるものはあまりないというのが私たちの経験。さらに、なぜコーディングエージェントが人間なら見つけるバグを見つけられないのかを突き止めるのに、時間と労力を使わなければならない
監査人として、毎週うちのハーネス(https://zkao.io/)が見つけられないバグを見ていて、ツールにそのバグを見つけさせるためにかなり興味深い手法を見つける必要がある。ここで言っているのは主に暗号学的脆弱性であって、単純な Web アプリのバグではない
だから各社が自前のハーネスも持ちつつ、経験に基づいて優れたハーネスを作ることに集中するサービスにもお金を払う、というのは十分あり得る話だと思う。多くのバグを見て、そのバグをハーネスに「教え込む」時間を使える監査会社が、こうしたことを最もうまくやれる可能性が高い
その一方で、分類にも同じくらい優れた手法が必要になる。そうでないと、私がバイブ監査と呼ぶような機械が生まれて、すでにバグバウンティの粗悪な AI 投稿や、あらゆる PR をレビューする AI ツールにうんざりしている開発者を、誤検知の洪水でさらに疲れさせるだけになる
結局、ハーネスがバグを一つも返さなければ、「ではバグがないという意味なのか？」と考え込むことになる。最終的には、最高のツールか最高のチーム、つまり何が最高のツールかを知っているチームを選び、そのそれが誰なのかを見極めるという評判ゲームに戻ってくる
セキュリティは間違いなくAI/LLM のユースケースとして非常に優れている。作業の大部分が、既知のセキュリティ問題のパターンを、分析対象であるきわめて精密なプログラミング言語テキストに照らし合わせることだからだ
目立つのは、最も強力なユースケースでは AI 企業が生の出力を売るのではなく、その手法をサービスとして売ろうとしている点だ。出力の価値が低い場合にはトークンを売る
もし AI トークンが一般的なソフトウェアアプリケーション開発において本当に新しい価値を生み出す魔法のようなものなら、直接トークンを売ったりはしないはずだ。トークンを抱え込んで、望むあらゆる業界の SaaS ソフトウェアを支配するために使うはずだ
株式市場で高額な講座を売る人が、自分の知識を使って株式市場で直接稼ぐよりも、講座を売るほうにより大きな利益があることを示しているのと似ている
AI トークンで製品を作るには、彼らが経験の少ない完成品の開発と販売まで行う必要があり、自社の顧客とも競合することになる。まだ地歩を固めている最中の AI ベンダーにとっては良い立ち位置ではない。既存事業だけでも対処すべきことは多いし、大きな気晴らしにもなって、戦略的にもそれほど価値が高くない
そこそこ成功した SaaS を運営して売却したことがあるが、疲れる部分やもどかしい部分は LLM ではどうにもならないものだった。製品をコーディングすることはボトルネックでもないし、成功を保証する要因でもない
彼らのトークンが本当に魔法のようなもので、既存産業に参入して既存プレイヤーを押しのけ、その業界で年率 100% 成長できるとしても、なおトークン販売を優先するほうがよい。それ自体が優れた事業だからだ
この理屈が示しているのは、せいぜい限界があるということくらいだ。トークンはソフトウェアのあらゆる領域ですぐに無限の金を生み出せるほど強力ではない。それは事実らしい
当初は、多くの会社がセキュリティ上の懸念から、従業員がリモート LLM にソースコードを書き込むことを禁じていた。今では、セキュリティ上の懸念ゆえに、すべてのソースコードをリモート LLM で分析すべきだと考え始めている会社が多い
Anthropic を信頼することが当たり前になれば、ソースコードへのアクセスが必要な、より多くのサービスを売れるようになる
少し話はそれるけれど、誰かがこの投稿の GitHub の良いリンクを dead/flag で片っ端から潰しているように見える。なぜそんなことをするのかわからない
一つの穴を見つけることは、常にすべての穴を塞ぐことより簡単だ。ハッカーも同じツールを持っているのだから、これは勝ち目のない軍拡競争だ
ここで言う非対称性は、LLM 以前のソフトウェアにもあった性質だ
かなり興味深い。しばらく似たようなツールを作って使ってきた:
https://github.com/bobinson/vulture
誤検知には苦しめられたし、Claude + MCP を貧者の監査ツールのように使ってきた。ここ数日ではNvidia ホスティングモデルでより良い結果が出ている
Claude がこのハーネスでトークンを効率的に使うかどうかわかるまでは、聞こえるほど有用ではないかもしれない
Anthropic がいまや特定ユースケース向けのハーネスを作って製品化しているのは明らかだ
セキュリティ向け Claude Design に相当するものだ
ハーネスが違い、パッケージングが違い、対象ペルソナが違うのだから、流通方法も当然違ってくる
面白いのは、Mythos について報告した企業の記事を見ると、どこも自前のハーネスを作っていることだ。Cisco はそのうちの一つの仕様を公開までした
しかし、これをどうパッケージ化して流通させるかを見つけたのは Anthropic だ。見事な市場参入戦略だ