世界を動かす技術を、日本語で。

AnthropicのAI駆動の脆弱性発見のためのオープンソースフレームワーク

概要

  • Claude を用いた自律型の脆弱性発見・修正リファレンス実装の紹介
  • セキュリティチーム との協業知見をもとにしたベストプラクティス
  • C/C++メモリ脆弱性 検出を中心に、他言語へのカスタマイズも可能
  • gVisorサンドボックス など安全設計を重視
  • Anthropic Claude Security などマネージド製品も案内

Claudeによる自律型脆弱性発見・修正リファレンス実装

  • Claude Mythos Preview 以降、複数組織のセキュリティチームと連携し得た知見を反映
  • 自動化された脆弱性発見・修正パイプライン のオープンソースリファレンス
  • SDKのみの軽量版ウォークスルー やベストプラクティスは、付属ブログやcookbookで提供
  • 本リポジトリは 保守対象外・コントリビューション非受付

マネージドサービス案内

  • Anthropic Claude Security :複数プロジェクト横断でソースコード脆弱性検出・修正を実施するホステッド製品
    • 多段階検証パイプライン で誤検知削減
    • トリアージ・修正検証・迅速パッチ生成 を一貫管理

リファレンス実装の特徴

  • Claude API (Bedrock, Vertex, Azure等)と連携可能
  • /quickstart, /threat-model, /vuln-scan, /triage, /patch, /customize 等のモジュールを用意
  • harness/ ディレクトリ:C/C++メモリ脆弱性をDocker+ASANで検出する自律パイプライン
  • 安全設計 :/quickstart等はファイルの読み書きのみ、/patchや自律パイプラインはgVisorサンドボックス内でのみ実行
  • セットアップ :scripts/setup_sandbox.sh実行後、bin/vp-sandboxedでパイプライン起動

主要ディレクトリ・スキル

  • /quickstart :初回体験・ガイド付き実行
  • /threat-model :脅威モデル構築
  • /vuln-scan :静的スキャン
  • /triage :検出結果の検証・重複排除・優先度付け
  • /patch :修正案生成・検証
  • /customize :他言語/検出器/脆弱性クラス向けカスタマイズ

セキュリティ設計

  • /quickstart, /threat-model, /vuln-scan, /triage はファイル操作のみで安全
  • /patch, 自律パイプライン はgVisorサンドボックス外での実行を拒否
  • 詳細 :docs/security.md, docs/agent-sandbox.md参照

導入・運用手順

Step 1(Day 1):脅威モデル作成+初回スキャン・トリアージ

  • 脅威モデル作成 →静的スキャン→トリアージ→修正案ドラフト
  • 成果物 :THREAT_MODEL.md, VULN-FINDINGS.{json,md}, TRIAGE.{json,md}, PATCHES/
  • コマンド例
    • claude > /quickstart
    • claude > /threat-model bootstrap targets/canary
    • claude > /vuln-scan targets/canary
    • claude > /triage targets/canary/VULN-FINDINGS.json
    • claude > /patch ./TRIAGE.json --repo targets/canary

Step 2(Day 2):C/C++ライブラリへの自律パイプライン適用

  • recon→find→verify→report の自律ループを既知脆弱なOSSライブラリで実施
  • 成果物 :再現可能なクラッシュ、エクスプロイトレポート、修正案
  • セットアップ
    • python3 -m venv .venv && .venv/bin/pip install -e .
    • ./scripts/setup_sandbox.sh
    • export ANTHROPIC_API_KEY=sk-ant-...
  • 実行例
    • bin/vp-sandboxed run drlibs --model <model-id> --runs 3 --parallel --stream --auto-focus
    • bin/vp-sandboxed patch results/drlibs/<timestamp>/ --model <model-id>
  • パイプライン7段階
    • Build, Recon, Find, Verify, Dedupe, Report, Patch

Step 3(Days 3-5):自社ターゲット向けカスタマイズ

  • Step 1スキル を自社コードに適用し、/customizeでパイプラインを移植
  • 質問例
    • 何が検出シグナルとなるか(例:ASANクラッシュ、例外、DNSコールバック等)
    • PoCの形(例:クラッシュ入力ファイル、HTTPリクエスト等)
    • ビルド・実行方法(例:Dockerfile、各言語のビルドコマンド等)
  • コマンド例
    • claude > /quickstart how do I customize this for ~/code/my-service?
    • claude > /threat-model bootstrap-then-interview ~/code/my-service
    • claude > /vuln-scan ~/code/my-service
    • claude > /triage ~/code/my-service/VULN-FINDINGS.json --repo ~/code/my-service
    • claude > /customize use ~/code/my-service/{THREAT_MODEL.md,VULN-FINDINGS.json} and ./TRIAGE.md
    • bin/vp-sandboxed run my-service --model <model-id> --runs 1

Step 4(Week 2):自律スキャン・トリアージ・パッチ適用の運用

  • 複数回のパイプライン実行→全結果のトリアージ→優先度順にパッチ生成・検証 を繰り返す
  • コマンド例
    • bin/vp-sandboxed run my-service --model <model-id> --runs 5 --parallel --stream --auto-focus
    • claude > /triage results/my-service/ --repo ~/code/my-service --auto --votes 5
    • claude > /patch results/my-service/<timestamp>/ --model <model-id>
  • /triage は複数回の結果を統合・重複排除・優先度再評価

参考資料・ドキュメント

  • Blog Post :導入知見・ベストプラクティス
  • Pipeline :構成図・各ステージ・CLIフラグ
  • Security :サンドボックス設計・マウント禁止事項
  • Agent sandbox :gVisor隔離・egress許可リスト
  • Customize :新規スタックへの移植方法
  • Patching :修正案生成・検証フロー
  • Troubleshooting :重複、レート制限、サブエージェントモデル固定
  • Safeguards :危険なサイバー作業のブロック

導入のポイント

  • 初日から小さく始めて徐々にスケールアップ することが成功の鍵
  • 設計に多くの時間を費やすより、まず実践することを推奨
  • 最初はcanary等のサンプルコードで全体像を把握、徐々に自社コードへ適用

このリファレンス実装は Claude API を活用した 自律型脆弱性発見・修正パイプライン の構築・運用を支援。 安全設計カスタマイズ性段階的導入 を重視し、セキュリティチームの現場運用に即したベストプラクティスを提供。

Hackerたちの意見

このリポジトリはメンテナンスされていなくて、貢献も受け付けてないよ。うーん :)

クロードはなんでそれを維持してないの?

これを運用するのにどれくらいお金がかかるのかな。https://github.com/anthropics/defending-code-reference-harne...によると、> おおよその目安として、エージェント1つあたり、キャッシュされていない入力トークンが約10K/min、出力トークンが約2K/minを見込んでね。並列処理はアカウントのITPM制限までスケールできるよ(大体100K ITPMにつきエージェント10個)。僕の予想では、Opusで数百ドル、Mythosで数千ドルかな。

ずっと動かしておく必要はないよね?最初に既存のコードベース全体を一度チェックして、あとは新しい変更を加えたときにCI/CDパイプラインで差分を一度確認すればいいんじゃないかな。実際にはそんなに簡単じゃないと思うけど、24時間365日動かす必要はないと思うよ。

コードを守るのに必要なトークンが、書くのに必要なトークンよりも多くなるのが明らかになってきたね。もしかしたら、桁違いに多いかも。

クロードのワークフローは、ウルトラコードモードで非常に似たような動作をするよ。タスクの複雑さによって、セッション使用制限の中で中程度の量を消費するんだ。ただ、APIを使うとすぐに高くつくかもしれないね。

彼らのマネージドサービスと比べると、その見積もりは期待の1/10くらいだと思うよ、コードベースによるけど。でもこの大きな数字でも、正式な契約で見つけるタイプの発見にかかるコストの1/10くらいになるかもね。PRレビューや/security-reviewでは出てこないようなことを、専門家のガイド付きでオープンソースフレームワークの前作業を経て見つけるわけだから。これには、その契約をどうやって進めるかを考える時間や遅延も含まれてない。率直に言うと、これが重要なら、これは単一のスキャンのための1ヶ月の予算でありながら、「安いもんだ」ってこと。とはいえ、その発見には専門家が必要だし、提案が役立つこともあれば、逆に有害になることもある。前作業の質によるね。IT部門の責任者へのおすすめ: これに数千ドル使って、怖がらせるページを使って予算を集めて、赤チームとの関係を築いて、見つけたり、トリアージしたり、必要なら修正を手伝ったり、社内チームを「セキュリティ意識」を持たせるためにトレーニングしてもらうといいよ。

確かに、セキュリティは素晴らしいAI/LLMのユースケースだよね。多くの作業は、既知のセキュリティ問題とプログラミング言語のテキストという非常に精密なものを照合するパターンマッチングに関わってる。強力なユースケースでは、AI企業はその技術を生の出力として売るんじゃなくて、サービスとして提供することを好むみたい。出力があまり価値がないユースケースでは、トークンが売られる。もしAIトークンがソフトウェアアプリケーションの開発において新しい価値を生み出すのがそんなに魔法のようなものであれば、直接トークンを売ることはないはず。彼らはトークンを蓄えて、自分たちが望む業界のSaaSソフトウェアを支配するために使うはずだよ。株式市場で高額なコースを売っている人が、コースを売ることで得られる利益が直接株式市場でお金を稼ぐよりも大きいことを示しているのと同じだね。

株式市場で高額なコースを売っている人が、コースを売ることで得られる利益が直接株式市場でお金を稼ぐよりも大きいことを示しているのと同じだね。あるいは、彼らは多様化したいのかもね。>もしAIトークンがソフトウェアアプリケーションの開発において新しい価値を生み出すのがそんなに魔法のようなものであれば、直接トークンを売ることはないはず。全く経験のない製品を作って売る必要があるし、自分たちの顧客と競争しなきゃいけないからね。まだ自分たちを確立しようとしているAIベンダーにはあまり良い状況じゃないよ。既存のビジネスで対処すべきことが多い中で、余計な気を散らすことになるし、戦略的にもあまり価値がないよね。

まあ、でもエコシステムを構築する方が長期的には価値があるっていう別の意見もあるよね。最初は多くの企業がセキュリティの懸念から、従業員にリモートLLMをソースコードに使わせないようにしてたけど、今は多くの企業がセキュリティのためにリモートLLMで全てのソースコードを分析しなきゃいけないと考え始めてる。Anthropicを信頼することが当たり前になれば、ソースコードへのアクセスが必要なサービスをもっと売れるようになるんじゃないかな。

それができるのは独占企業だけだよ、彼らはそうじゃないけど。

彼らはトークンを蓄えて、好きな業界のSaaSソフトウェアを支配するために使うんだ。これがどういうことか理解できない。私は半成功したSaaSを運営して売却したことがあるけど、疲れるしイライラする部分は、LLMが手助けできないことばかりなんだ。製品をコーディングすることがボトルネックでも成功の鍵でもないよ。

企業内のたくさんの人に電話やメッセージを送る「MetaSploit」AIの統合アップデートがまだ来てないのが驚きだよ。誰かが脆弱かもしれないと見つけたら、人間のレッドチームが引き継いだり、手動で導いたりするような感じで。

AIトークンがソフトウェアアプリケーションの新しい価値を生み出すのにそんなに魔法のようなものなら、直接トークンを売ることはないはずだ。彼らはトークンを蓄えて、好きな業界のSaaSソフトウェアを支配するために使うんだ。これには全く従わないね。Anthropicの収益は、トークンを売ることで年々10倍に成長してる。彼らのトークンは超魔法的かもしれないし、確立された業界に入って既存の企業を置き換え、そこで100%の年成長を得ることができるとしても、トークンを売ることを優先した方がいいのは、素晴らしいビジネスだからだ。君の主張が示しているのは、限界があるってこと。彼らのトークンは、すべてのソフトウェアの分野で瞬時に無限のお金を生むほど強力ではない。確かに、それは真実のように思えるね。

AIトークンがソフトウェアアプリケーションの新しい価値を生み出すのにそんなに魔法のようなものなら、直接トークンを売ってないはずだよ。ハードウェアが一般的に新しい価値を生み出すのにそんなに魔法のようなものなら、TSMCはサービスとしてチップを設計してるんじゃなくて、製造を売ってるはずだ。ちなみに、これはアメリカのチップ会社が昔やってたことだよ(シリコンバレーにシリコンがあった頃、台湾に食われる前の話)。もしTSMCが今製造しているすべてのチップを設計しなければならなかったら、ビジネスはずっと少なくなってたはず。逆に、チップを設計したい他の会社が最初に自分の最先端のファブを作らなければならなかったら、NVIDIAは存在しなかっただろうね。

こういうのって、ショップジグって呼ばれるものなんだよね。もし本気で欲しいならクロスカットスレッドを買うこともできるけど、ほとんどの木工職人は自分で作っちゃう。2年前は、自分でハーネスを作るのに結構お金がかかったけど、今はAI脆弱性研究をしてる人も少ないだろうしね。今は、こういうアイデアを参考にして、自分の作業スタイルに合ったものをリクエストするのが一番だと思うよ。自分のインターフェースやターゲット、努力の仕様、アラートも自分流にね。

「ショップジグ」って表現、いいね。多くのソフトウェアが一般的な用途から、すごく個別化された用途に変わってきたと思う。AIの時代の前は、自分の問題を解決するために何かを書くのにすごく人手がかかったから、他の人が再利用できるように余分な手間をかけることが多かった。でも今は、ほとんど手間がかからないから、ソフトウェアは一般化されないままなんだよね。インセンティブも変わってきたと思う。今は、自分が作っているものを共有することがほとんどなくなった。というのも、他の人にとって全く役に立たない可能性が高いし、もし彼らが似たようなものを必要とするなら、私のものを拡張したり修正したりする必要なく、自分が欲しいものを正確に作れるから。まるでジグみたいにね! 0: https://redfloatplane.lol/blog/17-why-share/ (関連する投稿もあると思うけど)

まさにその通り。何度も言ってるけど、「コンピュータを使うことは、自動的にコードを書いて実行させることを含む」って思ってるんだ(技術的じゃない人には気づかれないだろうけど!)。君が言ってることもその方向に向かってるよね。私たちの生活のために特化したツールを作る方がいいと思うし、モデルがリリースされるたびにそのツールの複雑さが増してる気がする。これらは本当に個人的なツールで、他の人が抱える問題を解決するけど、自分の特定の作業スタイルに密接に結びついていて、他の人に説明したり適応させたりするのは難しい。だから、ショップジグって感じ。こういうカスタムスクリプトやプログラムが10個くらいあるんだけど、大学時代以来こんな気持ちになったことはない!あの頃は自分のセットアップをカスタマイズするために時間がたっぷりあったけど…今はエージェントがいる!ある意味、これを友達全員に見せたいけど、どうやってそれが進むかを考えると、彼らは私の特有のクセを理解できないだろうなって気づく。彼らは私の問題をうまく解決する、かなり複雑な技術の塊で、これらは広い問題の特定のバージョンで、今のところサポートするつもりはない。これが進んでいるのは明らかだけど、まだ多くの人がコードはエリートのためのものだと思ってる。もしかしたら生産コードはそうかも…でも、他の部分については、すぐに君のお母さんやお父さんが自分のために書いたコードを実行するコンピュータを持つことになると思うよ。セキュリティ的には怖いけど、考えるとワクワクするね!

それには全く同意だね。

ちょっと話がそれるけど、誰かがこの投稿のGithubへの良いリンクを全部消してるみたいなんだけど、なんで?

とても興味深いね。似たようなツールをずっと使ってるんだけど、これだよ: https://github.com/bobinson/vulture 偽陽性に悩まされてて、ClaudeとMCPを貧乏人の監査ツールとして使ってたんだ。最近、NVIDIAのホストモデルでいい結果が出てきたよ。

アンスロピックはまだフランスの大部分の所有なのかな?それが彼らの広いエコシステムへのアプローチを説明するかも。

一つの穴を見つけるのは、すべての穴を塞ぐよりもずっと簡単だよ。ハッカーは同じツールを持ってるから、これは勝てない軍拡競争なんだ。

守る側には、攻撃者にはないコンテキストがあるんだよね。

LLMが脅威モデルの数学を大きく変えるのは明らかだけど、これだけじゃどうしてそうなるのかは説明できないよね。君が言ってる非対称性は、LLM以前のソフトウェアにも当てはまる特性だし。

ZAPやBurpと比べてどれだけ良いか見てみよう。https://github.com/SasanLabs/VulnerableAppでテストするつもりだよ、これはSasanLabsの下で作ったもの。

私たちの経験では、良いハーネスがないとcodexやclaudeからあまり得られないんだよね。コーディングエージェントがバグを見つけられない理由を理解するために、時間とエネルギーをかける必要がある。毎週、監査人として自分たちのハーネス(https://zkao.io/)が見つけられないバグを目にしていて、それを見つけるための面白いテクニックを考え出さなきゃいけないんだ。主に暗号的な脆弱性について話してるけど、単なるウェブアプリのバグだけじゃないからね。だから、企業は自分たちのハーネス(tptacekが言ってるやつ)を持つことと、経験から良いハーネスを作るサービスにお金を払うことの両方が重要だと思う。監査会社は多くのバグを見ていて、ハーネスにそれらのバグについて「教える」時間をかけられるから、最適だと思う。一方で、トリアージのための同じくらい良いテクニックを見つける必要がある。そうしないと、私は「バイブ監査」と呼んでいる機械ができてしまって、開発者たちを疲れさせるほどの偽陽性を生み出すだけになっちゃう。彼らはすでにバグバウンティやPRのレビューでクソみたいなAIの提出物に圧倒されているからね。結局、ハーネスがバグを返さないと、「バグがないってことなのかな?」って疑問に思うことになる。結局、最高のツールや最高のチーム(どのツールがベストかを知っている)を使いたいっていうレピュテーションゲームに戻ってしまうんだ。どれが一番いいのかを見極める必要があるね。