Claude Securityの脆弱性タイプと深刻度の判定基準

Claude Securityの深刻度は「脆弱性の分類」では決まりません。同じSQLインジェクションでも、公開APIから認証なしで突けるならHigh、ログイン後にテーブル構造の知識が要るならMediumです。基準はそのリポジトリでどこまで悪用できるかで、指摘ごとに個別に判定されます。

この記事は、検知対象の8分類と、High / Medium / Lowを分ける線引きを扱います。有効化手順や料金を含む全体像は別の記事にあります。

High / Medium / Lowを分ける3つの条件

公式サポート記事の定義は次の表のとおりです。判定の軸は、認証の要否、前提条件の数、そして攻撃手順を具体的に示せるかどうかです。

Mediumの基準では、認証の背後にあることと、1〜2個の前提条件が「または」で並んでいます。認証は前提条件の個数に含めない、別の軸です。Lowの例は近接性と数千回のリクエストを要する型で、前提の数だけでなく攻撃の規模も効くと読めます。

Lowの条件には、前提条件の数やローカル限定と並んで「具体的な攻撃手順が示されていない」が入っています。理論上はHighやMediumに近い脆弱性でも、攻撃チェーンが実演されていなければLowになりうるわけです。深刻度は、脆弱性クラスの危険度よりも、そのスキャンが示せた内容に紐づく作りです。

深刻度のしきい値は、設定で変えられません。Rapid7のスキャン結果を重大度とEPSSで切って優先付けする場合は、Rapid7 Bulk Exportコネクタの使い方が別の入口になります。

Highの指摘から手を付けるのが、チュートリアルの勧める進め方です。深刻度は、修正の優先順位を決めるためのラベルとして使われます。

指摘1件を読む順番

各指摘は、判定の根拠にあたるフィールドを一式で持っています。ラベルだけ見て優先度を決めず、根拠側から読み進めると、判定を自分で検証できます。

手順

指摘を開いたときの読み方

1. 1

   Impactで、放置したときに何が起きるかを見る

   深刻度ラベルの意味を、実害の言葉で確かめます。

2. 2

   Reproduction stepsで、前提条件を数える

   再現手順に出てくる「認証が要る」「特定ロールが要る」「大量のリクエストが要る」を、前節の表に当てはめます。

3. 3

   Locationで、該当のファイルと行に飛ぶ

   ソースにリンクされたファイルパスと行番号が付いています。デフォルト構成と自分の本番構成が違う場合は、ここで差分を確かめられます。

4. 4

   Recommended fixで修正方針を決め、Statusを動かす

   StatusはOpen / Dismissed / Resolvedの3値です。Dismissedにするときだけ、Dismissal reasonと任意のDismissal noteが付きます。

そのほかのフィールドは識別用です。Title(短い名称)、Details(何が起きているかの説明)、Category(次章の分類)です。Repository・Branch・Date createdで、どの対象をいつスキャンしたかが分かります。

検知結果は、提示される前に複数段階の検証を経ます。エージェントが自分の結果に反証を試みて、残ったものだけが表に出ます。プロダクトページは、この工程を「adversarial verification pass」と呼んでいます。深刻度とは別に、検証を通った指摘には信頼度(confidence)の評価と修正パッチの案が付いて返ります。深刻度は悪用しやすさ、信頼度は指摘がどれだけ確からしいかを示す、別の軸です。修正に進むときは、指摘からClaude Codeのセッションに移って、提案された修正を確認できます。パッチは誤りを含みうるため、とくに重要なシステムでは適用前に必ず内容を確かめるよう、プロダクトページは求めています。チュートリアルでは、指摘のremediationボタンから、その脆弱性の修正に絞ったセッションをClaude Code on the Webで開く手順になっています。

同じ分類でも深刻度が分かれる例

分類(何の脆弱性か)と深刻度(どれだけ悪用しやすいか)は独立した2つの軸です。優先順位は、分類名の印象ではなく個々の判定結果で組み立てます。スキャン結果のCSVから修正の優先順位表を作る手順は、脆弱性スキャンCSVから修正計画の表を作る手順にまとめています。

例

分類と深刻度の組み合わせ

• パス・ネットワーク

  SSRFが認証の後ろにあり、特定のロールが要るなら、Mediumの条件に当たります。同じSSRFでも、認証なしでデフォルト構成から届くならHighの条件です。

• 暗号

  タイミングサイドチャネルで近接性と数千回のリクエストが要るならLowです。alg=noneのJWTのように認証を丸ごと迂回できる実装は、認証なしで前提条件も要らないので、Highの条件を満たしえます。

• 認証・アクセス

  IDORで特定のロールが要るなら、Mediumの条件にある「特定のロール」に当たります。自分のコードでIDORを洗い出す手順はClaude CodeでIDORを表で洗い出す方法にあります。

検知する8つの脆弱性タイプ

公式サポート記事は、検知対象を8つの分類で例示しています。「例示」なので、列挙は網羅リストではありません。プロダクトページが重点に挙げるのは、メモリ破壊、インジェクション、認証バイパス、複雑なロジックの誤りといった、パターンマッチ型のツールが見落としやすい高深刻度の型です。とくに得意とされるのは、複数ファイルにまたがるコードの理解を要する、文脈依存の脆弱性です。

なお、この8分類はコードベース内の脆弱性が対象です。MCPサーバー経由のデータ流出のような接続先ツールの脅威モデルは、別の切り口で整理されています。

公式ページ同士で食い違う点

Claude Securityについては、サポート記事(support.claude.com)、プロダクトページ、Claude Academyのチュートリアルの3ページがあります。深刻度の定義はサポート記事にだけ書かれています。ほかの記述は、ページによって内容が違います。

くらべる

サポート記事とチュートリアルの記述差

FAQ

サポート記事

スキャンはClaude Mythos 5で動くと書かれています。深刻度は設定できないこと、スキャンが確率的であることも、ここにだけあります。GitHub.comとGitHub Enterprise Server以外のホスティングは対象外です。

運用編

チュートリアル・プロダクトページ

スキャンはClaude Mythos 5.1で動くと書かれています。チュートリアルには、StandardとExtendedの2つのスキャン強度、スコープの絞り込み、週1回の運用の目安も載っています。

Claude Code用のプラグインは、Claude Codeで使えるモデルをそのまま使います。Mythos 5でスキャンが動くのはclaude.ai/securityだけです。プラグインはベータ版で、コードを手元の環境に置いたまま、スキャンから検証、修正までをClaude Code内で行えます。

初回スキャンか大きな変更の後には、StandardとExtendedから選びます。より深く見たいときはExtendedです。

スキャン強度を上げる前に、課金の仕組みも押さえておく価値があります。サポート記事によれば、スキャンはトークンの直接コストだけが請求され、プラットフォーム料金は別にかかりません。チュートリアルは従量課金のため、リポジトリの大きさとスキャン回数に応じて費用が増えると説明しています。利用にはExtra usageの有効化が前提です。有効化後は、この機能専用の支出上限も設定できます。

対象プランも押さえておく点です。Claude Securityは、Claude Enterpriseのアカウントで使えるpublic beta(公開ベータ)の機能です。スキャンするユーザーには、組織のClaude.aiアカウントでプレミアムシートが要ります。

却下した指摘が以降のスキャンで再表示されない、という挙動はチュートリアルに載っています。プロダクトページも、記録された却下は引き継がれ、チームがどこで作業しても判断が見える、と説明しています。

同じリポジトリでも結果が揺れる理由

スキャンは、実行のたびに同じ結果が返る決定論的な仕組みではありません。サポート記事は「確率的(stochastic)に設計されている」と明記しています。固定パターンに当てるのではなく、エージェントが毎回コードの文脈を推論し直すためです。ロジックレベルの脆弱性まで拾える深さは、この作りの裏返しです。

この非決定性は、深刻度にも及びえます。Lowの条件に「攻撃手順が具体的に示されていない」が入っているので、攻撃チェーンの実演が深く進んだ回ほど高い深刻度になりえます。同じコードに対する再スキャンで、深刻度の内訳が変わる可能性があります。ここは、深刻度の条件と確率的設計を組み合わせた推論です。

揺れの抑え方は、スコープを絞ることです。大規模リポジトリやモノレポでは、モジュールやサブディレクトリ単位に絞ります。絞っても、エージェントは範囲外のコードから文脈を引けます。範囲を絞ると決定論性が上がり、エージェントの注意も集中するとチュートリアルは説明しています。

大きなリポジトリでは、ディレクトリを選んでスキャンするほうが成功率が上がるとチュートリアルは説明しています。所要時間もリポジトリの大きさ次第で、数分から数時間かかります。

ブランチの差分だけを手元で見たいときは別経路があります。Claude Code内蔵の/security-reviewです。対象がリポジトリ全体か差分かで使い分けます。

却下とエクスポートで判定を残す

却下(Dismiss)にはDismissal reasonを付けられ、任意でDismissal noteも書けます。チュートリアルは、これが「将来のレビュアーのための監査証跡」になると説明しています。Lowと判断した根拠が残っていないと、担当者が変わるたびに同じ検討をやり直すことになります。

指摘は、Project・Scan・Findingの単位でCSVかMarkdownに書き出せます。プロジェクト単位のwebhookで、スキャン完了と新規の指摘をSlackやJiraに送ることもできます。CSVは「何を、いつスキャンし、どう対応したか」の記録としても勧められています。

スキャンの頻度は、週1回がうまく回るチームが多いとチュートリアルにあります。週1回のスキャンは、月曜のトリアージ会議、スプリントの区切り、リリース前の確認など、すでにある予定に結びつけるとよいと、チュートリアルは説明しています。定期スキャンは、担当者を決めておくと最も効果が出ます。担当者がいないと指摘がたまり、未処理の山が避けられる対象になる、とも書かれています。

スキャンできるのは、自社が所有するか、スキャンする権利を持つコードだけです。サポート記事は、第三者のコードやオープンソースのリポジトリのスキャンを禁じています。他社製品の深刻度を調べる用途には使えません。

Zero Data Retention(ZDR)は適用されず、法律上必要な場合や利用ポリシー違反への対応のために、Anthropicがデータを保持することがあります。GitHubアプリの接続でつまずく場合の原因は、全体像の記事にまとめています。Claude Codeプラグイン版が出力する結果ファイルの形式は、Claude Security SARIFと結果ファイル4種の読み方で扱っています。

まとめ

Lowと判定された指摘でも、自社の本番構成がデフォルト構成と違うなら、Reproduction stepsの前提条件を自社環境で数え直す価値があります。深刻度のHighは、デフォルト構成のまま悪用できることを条件にしているためです。