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

Claude Securityの深刻度は「脆弱性の分類」では決まりません。同じSQLインジェクションでも、公開APIから認証なしで突けるならHigh、ログイン後にテーブル構造の知識が要るならMediumというように、そのリポジトリでどこまで悪用できるかで個別に判定されます。この記事では、公式サポート記事が定義する8つの脆弱性タイプと、High / Medium / Lowを分ける具体的な線引きを掘り下げます。Claude Securityの有効化手順や料金を含む全体像は既存記事にまとめているので、ここでは検知対象と深刻度の判定基準だけに絞ります。

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

公式サポート記事は、検知対象を8つの分類で例示しています。パターンマッチング型の従来スキャナーが見逃しやすい、複数ファイルにまたがるデータフローの追跡を前提にした分類です。

8分類のうち、認証・アクセス系(認証バイパス・権限昇格・IDOR/BOLA・CSRF・レース)が最も細分化されています。単一の脆弱性名ではなく「アクセスチェックが欠落・回避可能・競合状態にある」という共通の失敗パターンで束ねている点が特徴です。個々の名前を暗記するより、この失敗パターンの型で捉えるほうが、初めて見る脆弱性名にも当てはめやすくなります。なお、この8分類はコードベース内の脆弱性が対象です。MCPサーバー経由のデータ流出や権限昇格のように、接続先ツール自体の脅威モデルは別の切り口で整理されています。

分類ごとに、見つかる原因の性格も違います。

認証・アクセス系のレースは、チェックと実行の間に隙間ができるTOCTOU(Time-of-Check-to-Time-of-Use)型の不具合が典型で、単発のコードレビューでは気づきにくく、複数リクエストの並行実行を想定して初めて見えてきます。

デシリアライゼーションが「多くはRCEに直結」と注記されているのは、pickleやJavaのreadObjectが、データの中身ではなく型そのものを外部入力に決めさせてしまうためです。任意のクラスをインスタンス化できれば、そのクラスのコンストラクタやデストラクタに仕込まれた処理がそのまま実行されます。

プロトコル・エンコーディングの分類は他の7つと毛色が違い、単体のコードの誤りではなく、キャッシュ・プロキシ・アプリケーションという複数レイヤーが同じ入力を別の意味で解釈することから生まれます。Hostヘッダーの値をキャッシュキーとアプリケーションロジックの両方が別々に信用すると、片方を偽装するだけでキャッシュ汚染が成立します。ファイルをまたいだデータフローの追跡を前提にする設計は、まさにこの手のレイヤー間の食い違いを見つけるために効いてきます。

HIGH / MEDIUM / LOWは何で決まるか

深刻度は分類そのものではなく、そのリポジトリにおける悪用可能性で個別に判定されます。同じ分類が別のリポジトリでは別の深刻度に落ち着くことも珍しくありません。

この3段階を分けているのは単一の軸ではなく、複数の条件の組み合わせです。認証が不要かどうか、デフォルト構成のままで成立するか、現実的な前提条件がいくつ要るか、そして具体的な攻撃手順を実演できたかどうか——これらを合わせて判定します。認証の背後にあるというだけでMediumに落ちる場合もあれば、前提条件の数が同じでも攻撃経路を実証できなければLowにとどまる場合もあり、単純な「前提条件の個数」や「認証要否」の二分法には還元できません。深刻度のしきい値は設定で変更できません。組織ごとに基準を緩めたり厳しくしたりする余地は用意されていません。

CVSSのような業界標準の脆弱性採点は、攻撃ベクトル・攻撃の複雑さ・必要な権限・ユーザー操作の要否といった複数のサブ指標を別々に採点してから合成するのが一般的です。Claude Securityの3段階も、認証要否・デフォルト構成か・前提条件の数・攻撃経路の実証可否という複数の条件を踏まえて判定される点はCVSSと似た構造ですが、最終的にHigh/Medium/Lowの3値だけに集約する分、判定のプロセスはより単純です(この対比は本記事の整理であり、一次ソースがCVSSとの違いを明言しているわけではありません)。

見落としやすいのは、Lowの条件に「3つ以上の前提条件」「ローカルアクセス限定」と並んで「具体的な攻撃手順を示せない」が入っている点です。これは、理論上はHighやMediumに相当しそうな脆弱性でも、そのスキャンが実際に攻撃チェーンを再現できなければLowとして扱われることを意味します。深刻度は脆弱性クラスの理論的な危険度そのものではなく、そのスキャンが実演できた内容に紐づいています。次に扱うスキャンの非決定性と合わせて読むと、この設計の理由が見えてきます。

判定結果はどんなフィールドで届くか

各検知結果には、判定の根拠まで含めて次のフィールドが付きます。

• Title: 短い説明的な名称
• Details: 何が起きているか、なぜ問題かの説明
• Location: ソースにリンクされたファイルパスと行番号
• Impact: 対処しなかった場合に何が起こり得るか
• Reproduction steps: 再現・観測の手順を順序立てたリスト
• Recommended fix: 解決方法のガイダンス
• Severity: HIGH / MEDIUM / LOW
• Status: Open / Dismissed / Resolved
• Category: 前節の脆弱性タイプ
• Repository / Branch / Date created: スキャン対象の識別情報
• 却下時のみ: Dismissal reason(却下理由)とDismissal note(任意の補足)

深刻度は単独のラベルではなく、Reproduction stepsとImpactという2つのフィールドと組みで届きます。Highと判定された根拠を、担当者が再現手順から自分で検証できる設計です。この構造は、深刻度が実演できた攻撃手順に紐づいていることを実務面で裏付けています。

分類と深刻度は独立した2つの軸

分類(何の脆弱性か)と深刻度(どれだけ危険か)は完全に独立した2軸です。実務では、この2軸を掛け合わせて優先順位を組み立てることになります。

• メモリ安全性 × High: C/C++/Rustのunsafeコードで、認証なしに外部から到達できるバッファオーバーフロー。緊急度が最も高い組み合わせ
• 認証・アクセス × Medium: 特定ロールでのIDOR。悪用条件は限られるが、条件が揃えば実害が大きい
• 暗号 × Low: タイミングサイドチャネルのように、理論上は成立しても数千回の試行とネットワーク近接性が要る種類。優先度は下がるが記録には残す価値がある

分類だけを見て「暗号の脆弱性だから急がなくていい」と判断するのは早計です。同じ暗号カテゴリでも、alg=noneのJWTのように認証なしの前提条件なしで突破できる実装であれば、Highの判定基準に当てはまります。優先順位付けは、分類名ではなく個々の判定結果の深刻度を見て行うのが実務的な近道です。

同じリポジトリでも判定結果が変わることがある理由

Claude Securityのスキャンは、実行のたびに同じ結果が返る決定論的な仕組みではありません。固定のパターンにマッチさせる従来型スキャナーと違い、エージェントが毎回コードの文脈を推論し直しながら分析を進める、確率的な設計になっています。ロジックレベルの脆弱性まで捉える深さは、この作り方の裏返しです。

深刻度の判定基準に立ち返ると、この非決定性が効いてくる場所が見えます。Lowの条件の1つは「具体的な攻撃手順を示せない」ことでした。攻撃チェーンを実際に組み立てられるかどうかはエージェントの推論に依存するため、同じ脆弱性でもスキャンの実行ごとに、実演できる攻撃手順の完成度が変わり得ます。今回の実行ではMediumと判定された指摘が、次回のより深い推論でHighに引き上がる、あるいはその逆も起こり得るということです。初回スキャンや大きな変更の後に「Standard」より深い「Extended」を選べる設計も、この推論の深さを調整する余地として理解できます。

公式サポート記事は、検知結果を提示する前に複数段階の検証を経ることも説明しています。エージェントは指摘をそのまま出すのではなく、自分自身の判定結果に対して反証を試みてから表に出す設計です。単に1回のスキャンで見つけた内容をそのまま報告しているわけではありません。

裏を返せば、Lowと判定された指摘を「大した問題ではない」と読み替えるのは早計です。同じコードをもう一度、より広い文脈を与えてスキャンし直せば、MediumやHighに格上げされる余地が理論上は残っています。

公式は、深刻度の高いものから優先して着手することを推奨しています。加えて、却下(Dismiss)の際に理由(Dismissal reason)と任意の補足(Dismissal note)を残しておくと、監査証跡として機能するとも案内されています。誤検知や対象外と判断した結果を理由付きで却下すると、以降のスキャンでは再表示されません。判定基準が「そのリポジトリでの悪用可能性」という個別事情に依存する以上、なぜLowと判断したかの記録が残っていないと、担当者が変わるたびに同じ検討をやり直すことになりかねません。

大規模なリポジトリやモノレポでは、全体ではなくモジュールやサブディレクトリ単位にスコープを絞ると、スキャンの決定論性が上がり、エージェントの注意もその範囲に集中します。Enterpriseの組織単位のスキャンではなく、ブランチの差分だけを手元で見たい場合はClaude Code内蔵の/security-reviewが軽量な選択肢になります。分類と深刻度の考え方自体は共通していますが、対象範囲がリポジトリ全体か差分かで住み分けが決まります。

まとめ

Claude Securityの脆弱性タイプは、インジェクション系・パス&ネットワーク系・認証&アクセス系・メモリ安全性・暗号・デシリアライゼーション・プロトコル&エンコーディングの8分類に整理されています。深刻度はこの分類ではなく、認証の要否・デフォルト構成のままで悪用できるか・現実的な前提条件がいくつ要るか・攻撃経路を実演できたかという複数の条件を組み合わせて、リポジトリごとに個別判定されます。しきい値は設定変更できず、判定結果にはReproduction stepsとImpactという検証可能な根拠が付いてきます。分類と深刻度が独立した2軸である以上、優先順位付けは分類名の印象ではなく個々の判定結果を見て行うのが実務上の近道です。