Shannonとは｜ソースコードを読んでから攻撃するwhite-box設計のAIペンテスターを実測で解説

Shannon（KeygraphHQ）は、まずソースコードを読んで攻撃経路を計画してから実exploitを実行する、white-box（白箱）設計のAIペンテストエージェントです。AIエージェントが実際にアプリを攻撃してPoC（概念実証）で脆弱性を裏付ける設計自体はすでに珍しくありませんが、多くのOSSは実アプリを外側から動かして探るblack-box（黒箱）寄りの探索から攻撃を始めます。Shannonはこれとは逆の順序を採ります。GitHubスター数は47,147（2026年8月24日実測）に達し、2026年8月にはメジャーバージョンのShannon 2.0が公開されました。

開発者向けセキュリティ全般の考え方は、まずサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説で土台を掴んでおくと、Shannonの位置づけが理解しやすくなります。

Shannonとは——ソースコードを読んでから攻撃するAIペンテスター

Shannonは、TypeScriptで実装されたAIペンテストエージェントです。攻撃前にソースコード解析を行うwhite-box pentesting（白箱型ペンテスト）を採用している点が最大の設計上の特徴です。リポジトリの作成は2025年9月27日で、開発元のKeygraphは、本リポジトリ（Shannon Open Source）を無償OSSとして公開する一方、同じエンジンを強化した継続的ペンテスト製品「Keygraph platform」を商用展開しています。

READMEが掲げる存在理由は明快です。Claude CodeやCursorのおかげで開発チームは絶え間なくコードを出荷するようになったのに、ペネトレーションテストは年に1回しか行われない。この差分が生むギャップを埋めるために、ビルドやリリースのたびに回せる自動ペンテストを用意した、という位置づけです。

処理の流れは、脆弱性クラスごとにエージェントを並列で走らせるマルチエージェント構成になっています。

・Pre-Reconnaissance：対象リポジトリのソースコードを走査する
・Reconnaissance：攻撃面（attack surface）をマッピングする
・Vulnerability エージェント：Injection・XSS など脆弱性クラスごとに並列で分析する
・Exploit エージェント：クラスごとに実際の攻撃を実行し、成立したものだけをレポートへ回す

「攻撃経路をコードから計画してから実行する」という順序自体が、後述するStrixのような既存OSSとの最大の違いです。実行時、対象リポジトリは読み取り専用（read-only）で使い捨てのworkerコンテナ内にマウントされ、結果はローカルのワークスペースに書き出されます。

Shannonは何を検出でき、何を検出しないのか——OWASP WSTG 109項目の実数

導入判断でいちばん効くのはここです。Shannonはリポジトリ直下に COVERAGE.md を置き、OWASP WSTG（Web Security Testing Guide）のチェックリストに対して、どの項目に対応しているかを自己申告しています。しかも「動的検出は他の領域にも及ぶことが多いが、透明性のために一貫して確実に捕まえられるものだけにチェックを付けた」と断り書きがあります。

この対応表のチェック印を実際に数えました。

COVERAGE.md の「What Shannon Does Not Cover」節も率直です。能動的に攻撃を成立させられないもの——脆弱なサードパーティライブラリの使用、弱い暗号アルゴリズム、安全でない設定——は報告しない、と明言しています。これらは別製品の Keygraph Code Security（SAST）が担う予定だそうです。

ビジネスロジックが0/10なのも同じ理屈です。「この割引が二重適用できてしまう」といった欠陥は、コードを読んで挙動を再現できても、それが仕様違反かどうかは人間にしか判定できません。証明可能性を基準に据えると、この領域は自動的に落ちます。

white-box vs black-box——Strixとの設計思想の違い

当サイトでは既に、AIエージェントが実際にアプリを攻撃してPoCで脆弱性を裏付けるOSSとしてStrixとは｜AIが実際に攻めてPoCで裏取りするOSSペンテスターを実測で解説を解説しています。Shannonの「実際に攻めてPoCで確認する」という骨格自体はStrixと共通していますが、攻撃の起点が異なります。

white-box設計は、ソースコードへのアクセスがある内製アプリの検査に向く一方、対象のコードを読めない外部SaaS等の検査には原理的に使えません。逆にblack-box寄りの探索は対象コードが無くても動く代わりに、コードを読まないと分からない設計レベルの欠陥は見落としやすくなります。どちらか一方が優れているというより、検査対象がソースコードを読めるかどうかで使い分けるのが実務的な判断です。

AIペンテスト系OSSは他にも複数存在しますが、実装形態はそれぞれ異なります。NeuroSploit解説｜100種の脆弱性に対応するAI駆動の自律ペンテストOSSを設計と防御視点で読むは100種類の脆弱性への対応を謳う自律ペンテストOSS（MIT）で、開発規模はShannonより小さめです。OWASP APTS｜AIエージェント時代の自律型ペネトレーションテスト基準を読むは個別ツールではなく、この種のAIペンテストエージェント全体が満たすべき標準規格の解説です。乱立するAIペンテストOSSを比較する際は、「実装形態（単体CLI／フレームワーク／サブエージェント集）」と「攻撃の起点（white-box／black-box）」の2軸で整理すると位置づけが把握しやすくなります。

OSS版と商用版の線引き——開発元が明言している限界

Shannon 2.0のREADMEには「Editions」という節があり、OSS版と商用のKeygraph platformの機能差が表で示されています。ここが率直で、OSS版の限界を開発元自身が書いている点は評価に値します。

とくに目を引くのが「Analyze」の行です。OSS版は “Basic LLM pass-through of source to plan attacks”——つまり攻撃計画のためにソースをLLMへ素通しするだけ、と書かれています。商用版はCode Property Graph・SAST・到達可能性つきSCA・シークレット・IaC・コンテナスキャンで実際にコードベースを解析します。

これは記事の見出しにもした「ソースコードを読んでから攻撃する」という表現を、正確に理解するうえで重要です。OSS版がやっているのは、本格的な静的解析器を回すことではなく、LLMにソースを読ませて攻撃経路を考えさせることです。white-boxであることは間違いありませんが、その中身はモデルの読解力に依存します。

AGPL-3.0というライセンス選択も、この線引きと地続きです。AGPL-3.0はコピーレフトが強く、改変版をネットワーク越しにサービス提供する場合にもソース公開義務が及びます。SaaSとして再提供したい事業者は事実上、商用ライセンス契約を選ぶことになります。自社内で使うだけなら問題になりませんが、プロダクトに組み込んで顧客へ提供する構想がある場合は、着手前に条件を確認してください。

Shannonのインストールと実行——Quick StartとSARIF出力

Shannonの実行にはDocker（workerコンテナ）とNode.js 18以上、そしてAIプロバイダの資格情報が必要です。README記載のQuick Startは以下の流れです。

# 対話ウィザードで資格情報を設定する
npx @keygraph/shannon setup

# 対象URLとローカルのリポジトリパスを指定して実行する
npx @keygraph/shannon start -u https://your-app.com -r /path/to/your-repo

-r オプションでソースコードのパスを渡す点が、URLだけで動くblack-box型のOSSとの実行フロー上の違いです。ソースコードを渡さないと、white-box設計の前提である「攻撃経路の計画」自体が成立しません。

モデルの選択肢自体は広く、Anthropic・OpenAI・xAI・AWS Bedrockに加え、Anthropic Messages API互換またはOpenAI Chat Completions / Responses API互換のエンドポイントであればカスタムベースURLで接続できます。Ollama・vLLM・LM Studioでのセルフホストや、OpenRouter・LiteLLMのようなゲートウェイも対象です。ただしREADMEは、ローカル／セルフホストモデルについて「技術的にはサポートするが推奨しない」と正直に書いています。理由は、Shannonの指示やツール利用の制約をフロンティアモデルほど確実には守らない可能性があるためです。

もうひとつ実務で効くのがSARIF 2.1.0での出力です。設定で有効にすると、検出結果を構造化JSONに加えてSARIF形式で吐けます。SARIFは静的解析結果のOASIS標準なので、コードスキャンサービス・脆弱性管理プラットフォーム・セキュリティダッシュボード・CI/CDパイプラインのうち、SARIFを読めるものへそのまま流し込めます。単発の手動実行から、CIに載せる運用へ進むための出口がここです。

実行が中断しても、resumable workspacesにより完了済みエージェントを再実行せずに再開できます。長時間かかるスキャンでは効いてきます。

実際のレポートを先に読む

リポジトリには sample-reports/ として、意図的に脆弱なアプリを対象にした実物のレポートが3本同梱されています。手元でスキャンを回す前に、これを読むのが最短です。

Juice Shopのレポートを読むと、粒度がよく分かります。INJ-VULN-01: SQL Injection Authentication Bypass、AUTH-VULN-05: Brute Force Login Attack (No Rate Limiting)、AUTH-VULN-07: Password Cracking via MD5 Hashes、AUTH-VULN-10: Token Replay After Logout のようにIDが振られ、再現手順とコマンドが添えられます。

注目したいのは「Confirmed Vulnerabilities Without Successful Exploits（確認できたが攻撃は成立しなかった脆弱性）」という節が別に設けられている点です。HTTPでの資格情報傍受やHSTS未設定といった項目がここに入っています。攻撃が成立したものと、指摘に留まるものを分けて書く——proof-by-exploitationを掲げる以上、当然ではありますが、この分離がレポート構造として明示されているのは実務では使いやすい設計です。

安全な運用——許可・本番回避・プロンプトインジェクション

docs/safety.md は「新しい環境でShannonを走らせる前に読め」という一文から始まります。実務上、押さえるべきは3点です。

① 書面での許可が要る。 対象システムの所有者から明示的な書面の承認を得ていることが前提です。所有していないシステムへの無許可のスキャンや攻撃は違法であり、Keygraphは誤用の責任を負わないと明記されています。

② 本番環境で実行しない。 Shannonは受動的なスキャナではなく、Exploitエージェントが実際に攻撃を実行してアプリの状態やデータを変えうるためです。公式が挙げる副作用は具体的です。

・新規ユーザーの作成
・データの変更または削除
・テストアカウントの侵害
・インジェクション攻撃による意図しない副作用の誘発
・想定外の外向き通信の発生
・レポートや成果物へのexploit生成物の書き込み

公式は最大限の隔離のために、使い捨ての仮想マシン内での実行を推奨しています。

③ AIペンテスター自身がプロンプトインジェクションの標的になる。 ここが、従来のスキャナには無かった論点です。safety.mdは「信頼できない、あるいは敵対的なコードベースにShannonを向けるな」と明記しています。ソースコードを読み込むAIツールは、リポジトリ内に仕込まれた悪意ある記述に影響されうるためです。

加えて公式は「検証は必須」とも書いています。proof-by-exploitationを採っていても、最終レポートに根拠の薄い記述や誤った詳細が混じりうるため、人間のレビューが不可欠だという立場です。生成された再現手順を鵜呑みにせず、少なくともCritical判定のものは手で追試する運用が要ります。

なお、AnthropicとOpenAIはサイバーセキュリティ用途にリアルタイムのセーフガードを適用しており、スキャンの途中で中断されることがあります。READMEは初回実行の前に、各プロバイダが用意している正当なセキュリティテスター向けの手続きを済ませるよう案内しています。

実行前の対策チェックリスト

上記を運用に落とすと、実行前に固めるべき対策は次の6点になります。いずれも公式ドキュメントの記述をそのまま作業項目にしたものです。

3の「使い捨てVM」は、2と重複しているようで役割が違います。2はアプリ側（対象）を守る話、3はShannonを走らせるホスト側を守る話です。攻撃を実行する側のマシンにも生成物が残るので、両方を分けて考える必要があります。

バージョンごとの影響範囲——リリースのタイムラインと版の選び方

Claude Codeサブスクの扱いが版で変わるため、影響範囲をリリースのタイムラインとあわせて整理しておきます。タグの日付は本記事執筆時点でのリポジトリ実測値（git tag と各タグのコミット日）です。

つまり選択は二択です。Claude Codeのサブスクで動かしたいならv1.9.0に固定する（ただし2026年7月4日で更新が止まった系統になる）か、最新版を使ってAPIキーまたはOpenAI Codexサブスクで動かすか。前者を選ぶ場合、v2系で追加されたSARIF出力やresumable workspacesは使えないと考えるべきです。

v2.0.0以降のリリース間隔は7〜14日程度で、開発は明確に最新系統に寄っています。特別な事情がなければ最新版＋APIキーが素直でしょう。

なお、この版の分岐は「Shannon側の都合」というより、Claude Agent SDKからの基盤入れ替えに伴うものと読めます。v1.9.0がClaude Agent SDKベースの最終リリースだと明記されている以上、v2系はエージェント実行基盤そのものを差し替えたことになります。同種の乗り換えは他のAIエージェントOSSでも起きうるので、サブスクリプション前提で運用しているツールは、メジャー更新のたびに認証経路が維持されるかを確認する習慣を持っておくと安全です。

開発体制をどう見るか

★47,147に対してcontributorは7名（ajmallesh 123コミット、ezl-keygraph 82、keygraphVarun 35 ほか）。全員がKeygraph社の関係者と見られ、外部コミュニティからの継続的な貢献はまだ限定的です。

これはOSSとしては両義的に読めます。専任チームが商用製品と共通のエンジンを開発しているため、star数だけ伸びて放置される個人プロジェクトのリスクは小さい一方、開発の方向は1社の製品戦略に従属します。実際、Editions表が示すとおり高度な解析機能は商用版側に置かれており、OSS版がどこまで拡張されるかは同社の判断次第です。open issueは30件、最終pushは2026年8月21日で、開発自体は活発に続いています。

まとめ

年1回のペンテストと毎日の出荷の間にあるギャップを埋める、という問題設定自体は的確です。そしてShannonは、その埋め方として「証明できるものだけ報告する」という厳しい線を引きました。WSTG対応表の偏り——認証・認可は満点でビジネスロジックはゼロ——は、その線引きが実装まで一貫している証拠でもあります。

導入するなら、期待値を正しく置くのが先決でしょう。これはペンテスターの代替ではなく、認証・認可まわりを高頻度で殴り続けてくれる自動化です。設定不備もビジネスロジックも拾いません。そのうえでCIにSARIFで載せられれば、「364日の空白」のうち相当な部分は埋まります。まずは sample-reports/ の3本を読んで、出てくるレポートが自分たちの運用に載る粒度かどうかを確かめるところからをおすすめします。

参照ソース

・KeygraphHQ/shannon（公式リポジトリ・README） — Shannon 2.0のEditions表、Architecture、Quick Start、Claude Codeサブスク非対応（v1.9.0が最終対応版）の記述元
・COVERAGE.md（OWASP WSTG対応表） — 本記事の「109項目中52項目」はこのチェック印を実数集計したもの。「What Shannon Does Not Cover」の出典
・docs/safety.md（安全と制約） — 本番回避・使い捨てVM・プロンプトインジェクションリスク・人間レビュー必須の記述元
・sample-reports/（同梱の実レポート3本） — Juice Shop・crAPI・c{api}tal API に対する出力例。行数と章構成の実測に使用
・Keygraph公式サイト — 商用Keygraph platformの位置づけ