「Claude Codeに全部やらせる時代が来た」のか検証してみた

はじめに

こんにちは。セキュリティエンジニアの@okazu_dmです。
この記事は、最近リリースされたLLMベースのセキュリティスキャンツールとしてclaude-security-scan を使ってみた所感の記事です。

---

先週、以下の記事を見つけました。

検出率100%という結果が紹介されており、Claude Codeに全部やらせる時代が来た、というタイトルから「楽な時代が来たな」と思ったのですが、実際のところどの程度やらせることができるのかを検証するため、より網羅的に脆弱性が仕込まれている OWASP Juice Shop で再評価してみました。本記事ではその結果と、LLMベースのセキュリティスキャンツールに対する考察をまとめます。

なお、claude-security-scan はClaude Codeのslash commandとして実装されており、ソースコード解析と依存関係チェックを行う /full-scan と、起動済みアプリケーションに対する動的スキャンを行う /security-scan の2種類が用意されています。

やったこと

検証は以下の手順で実施しました。

1. 上記リポジトリの commands/ 以下を、スキャン対象側の .claude/commands/ にコピー
2. OWASP Juice Shop（v19.2.1）を clone
3. LLMが「答え」を直接読めてしまうファイルを削除
4. /full-scan を実行
5. アプリを localhost:3000 で起動し /security-scan を実行

LLMが正解を覗き見しにくくするため、削除したファイル/ディレクトリは以下の通りです。
（スコアボード用のファイルなど、完全に消すと起動に支障が出るものは残した）

challenges.yml や codefixes/、SOLUTIONS.md、hacking-instructor/ 等は脆弱性の所在や攻略手順を直接的にあるいは間接的に示しており、AI向け補助ファイル（AGENTS.md、.cursor/、copilot-instructions.md など）にも同様にヒントが含まれる可能性があるため除外しました。テスト系ディレクトリも、攻撃ペイロードの正解例を含むため対象外としています。

結果

/full-scan と /security-scan の検出件数は次の通りでした。/security-scan は 1 回目の実行後に security-agent.config.yml の scope 設定を反映するため、2 回目を上書き実行しています。

スキャン	Critical	High	Medium	Low
/full-scan（静的＋依存）	17	52	6	0
/security-scan（1回目）	4	3	4	3
/security-scan（2回目、scope適用後）	4	4	3	3

/full-scan の内訳はソースコード所見 41 件、依存パッケージのCVE 34 件、シークレット 4 件です。

OWASP Juice Shop の主要な脆弱性カテゴリ（14分類）に対する検出状況をまとめると以下のようになりました。

カテゴリ	静的	動的	評価
SQL Injection	✓	✓（admin JWT 取得を実証）	良
NoSQL Injection	✓	✓（28件のレビュー一括改ざんを実証）	良
Eval / SSTI / vm2 RCE	✓	✗	静的のみ
XXE	✓	✗	静的のみ
Auth / JWT（alg:none、ハードコード鍵）	✓	✓	良
Reset Password / 2FA / CAPTCHA	△	✗	弱
Access Control / IDOR	△	△	部分
XSS（Reflected/Stored/DOM）	✓（11件）	✗	静的網羅、動的0件
CSRF / Open Redirect / SSRF	✓	△	部分
機密ファイル漏洩（/ftp 配下）	✗	✓	動的のみ
暗号関連（MD5、HMAC、BIP-39）	✓	—	良
依存パッケージのCVE	✓（34件）	—	良
ビジネスロジック	✗	✗	構造的に未対応
ファイルアップロード／デシリアライゼーション	△	✗	弱
Race Condition / TOCTOU	✗	✗	構造的に未対応

検出率を「（こちらで勝手に設定した）脆弱性クラス単位」でみると概算 60〜70%、Critical 級に絞ると 80% 以上が捕捉できていました。
これは冒頭で紹介した記事内のカバレッジに関して言及されている内容とも整合します。
一方、Juice Shop のスコアボードに登録されている個別チャレンジ（約100件）単位でみると、後述の通り 11% 程度に留まります。脆弱性クラスとしては検出できていても、各チャレンジを成立させる具体的なペイロードまでは到達していない、という構図です。
ただし、個別チャレンジの結果はあくまで動的スキャンの範囲に留まる点には注意が必要です

考察

検出結果の偏りについて

得意/不得意は静的スキャンと動的スキャンで対照的でした。

静的スキャンが捕捉できた領域は、大きく以下のようなパターンマッチに帰着できるものでした。

• ソース上に明確なシンクが存在する脆弱性（eval()、$where、bypassSecurityTrustHtml など）
• ハードコードされた鍵やシークレット（RSA秘密鍵、BIP-39ニーモニック、Alchemy APIキー、cookie secret）
• 既知CVEを持つ依存パッケージ（jsonwebtoken、vm2、marsdb、lodash 等）

逆に静的スキャンが弱かったのは、コード単体では脆弱性の成立が判断できない領域です。Race Condition（likeProductReviews.ts の sleep(150) を挟む、check-then-actパターン）は典型例です。SPA上で動くDOM XSSや、ビジネスロジック由来の欠陥（プレミアム機能のバイパス等）も同様に静的では難しい対象でした。

動的スキャンは「実際に攻撃が成立する」ことを示した点は評価ポイントです。今回の検証では、SQL Injection による admin JWT 取得、JWT alg:none による認証バイパス、POST /api/Users への mass-assignment による admin 作成、NoSQL Injection による全レビューの一括改ざん（28件）の 4 件を実証できました。

一方で動的側にも構造的な弱点が見えました。

• 実際にテストリクエストが送られたエンドポイントは概算 60件中 18件と狭い
• SQLi の ' OR 1=1-- 1種で通らないバリアント（メールアドレス別の xx@yy.zz' -- 形式など）に到達できない。
  • 今後のペイロードの充実で改善できそう
• ヘッドレスブラウザを動かしていないため、SPAのフロントエンドで発火する DOM XSS は実証できない
• 並列リクエストを発射するロジックがなく、Race Condition 系のチャレンジは原理的に再現できない
• パスワードリセット、2FA、CAPTCHAバイパスなどの認証フロー周辺は専用シナリオが用意されていない

総じて、静的と動的の二段構成という方針自体は妥当だと感じました。静的だけでは「実害があるか」を断定できず、動的だけでは「絶対数」が出ない以上、両者を組み合わせること自体は素直なアプローチです。ただし今回の構成では動的側の手数が少なく、/full-scan で静的に発見できた指摘の一部しかランタイムで再現できていません。

精度について: LLM自体は信頼して良いのか

今回の結果から、LLMベースのセキュリティスキャンツールの精度は「観点として何を見るか」のテンプレ化品質に強く依存している、というのが率直な感想です。

LLM自体は、ソースを読んで「危なさそうな箇所」を列挙する能力は十分に持っており、bypassSecurityTrustHtml のような Angular 特有の問題や、alg:none を許容する jws の使い方などは安定して指摘できていました。一方で、以下のような限界も観測されました。

• 典型的な脆弱性ルールに当てはまらず、観点としてあらかじめ与えられていないパターンは見落とす（Race Condition のシグネチャ「sleep を挟む check-then-act」は気付かれなかった）
• 同じ入力でも実行ごとに観点や深さがぶれる可能性が残る（プロンプトベースである以上当然の問題）

つまり、LLM単体ではなく、「LLMに何を観点として渡すか」「設定が網羅性を毀損していないか」「動的側の手数を増やせているか」という運用側の作り込みが、結果のばらつきと品質を支配する印象を持ちました。LLMの出力は読みやすく一見もっともらしいので、レポートの存在自体を「網羅できた」根拠にしてしまうリスクは意識する必要があります。

ベンチマークの選定について

冒頭で紹介した記事では検出率100%と報告されていましたが、今回 OWASP Juice Shop で再現した範囲では脆弱性クラス単位で 60〜70%、チャレンジ単位では 11% 程度に留まりました。

両者を直接比較するのは公平ではなく、これは主に対象ベンチマークの差から来ています。Juice Shop は教育目的で約 100 のチャレンジが OWASP Top 10 全般にわたって意図的に仕込まれており、ビジネスロジック、ステガノグラフィ、暗号解析、Race Condition のように「LLMラッパーでは原理的に取りにくい」ものも含まれています。一方、検出率100%とされたサンプルでは、典型的なパターンに沿った脆弱性が中心であった可能性が高く、その分網羅率は出やすくなります。

LLMベースのスキャンツールを評価するベンチマークとしては、最低限以下の条件が必要だと考えています。

• 観点の多様性: SQLi/XSS のような典型から、認証フロー、ファイルアップロード、Race Condition、ビジネスロジックまで幅広く含む
• False Negative の客観評価ができる: 仕込まれた脆弱性のリストが既知であり、検出漏れを定量化できる
• 学習/参照データから汚染されていない: AI向けヒントファイル（AGENTS.md、.cursor/、攻略ガイドUI、回答yaml など）を除去した状態で測定する
  • これはOWASP Juice Shopが満たしているかはやや怪しいですが、今回の結果を見る限りは、少なくとも「LLMが正解を直接読んでしまう」ような状態ではなさそうでした。

その点で OWASP Juice Shop は、上記3条件をいずれも満たしており、LLMベースのセキュリティスキャンを比較する基準としては妥当な選択肢だと感じています。一方で、Juice Shop の中でも「LLMラッパーでは原理的に取れない」カテゴリ（ステガノグラフィ、暗号解析、ビジネスロジック）が一定数含まれているため、検出率の絶対値はそのまま「ツールの実力」とは読めない点には注意が必要です。同じ条件で複数のツールを評価したときの相対比較に用いるのが現実的だと考えます。

Shannonで試した結果との比較

以下の記事で、こちらもLLMを用いたセキュリティスキャンツールのShannonを用いてOWASP Juice Shopをスキャンした結果が報告されていました。

単純にJuice Shop内のスコアボードの割合で比べてみると、Shannonは15%、今回対象としたclaude-security-scanは11%でした。
Shannonとclaude-security-scanに共通して言えることは、細かい手順をプログラムで冪等な形として実装せずに、LLMの能力を最大限活かす形でスキャンを実現しています。これは、ばらつきが出やすく品質の維持の工夫が必要になるという点はありますが、その一方でLLMのバージョンアップに伴う性能向上の恩恵を最大限受けられるというメリットがあり、今後もこのような形でLLMのラッパーのようなセキュリティスキャンツールが増えていくのではないかと考えています。

まとめ: 実用的ではあるが、限定的な利用を推奨

OWASP Juice Shop に対する claude-security-scan の検出率は、脆弱性クラス単位で 60〜70%、Juice Shop チャレンジ単位で 11% という結果になりました。Critical 級の主要な脆弱性（SQLi、JWT、NoSQLi、RCE、ハードコード鍵、依存CVE）は概ね捕捉できている一方で、認証フロー周辺、ファイルアップロード、CSRF、ビジネスロジック、Race Condition は構造的に弱く、動的スキャンの拡充とペイロード辞書の充実が改善につながると思われます。

冒頭で述べたように、Claude Codeに全部やらせる時代が来たのか、という疑問についての答えとしては、残念ながら到底「全部やらせる時代が来た」とは言えない状況でした。
総合的には、ツール自体の精度はともかく組織にセキュリティスキャンという文化を導入する入口としてこのように安価なソリューションから始めるのは良いように思います。

LLMベースのセキュリティスキャンツールの評価では、ベンチマークの選定が結果を大きく左右します。「検出率100%」のような数字は、その背後にあるベンチマークの観点多様性とFalse Negative評価可能性を確認しないと意味を持ちません。同じ観点で Shannon と比較する余地が残っているのは、今後のこの分野の盛り上がりを示唆していると感じました。

参考文献

• LLMを用いたセキュリティスキャンツール claude-security-scan の紹介
• Shannon を用いた OWASP Juice Shop スキャン結果
• OWASP Juice Shop
• OWASP Top 10