脆弱性対応は「緊急度」と「本番反映の準備」を分けて判断する

Larry

コードスキャンから数百件の警告が届いても、深刻度の高い順に直せばよいとは限らない。脆弱な部品が含まれていても、実際の処理が問題箇所を通らないことがある。反対に、点数は目立たなくても、公開された入口から低信頼の入力が届き、すでに悪用の兆候まで出ているかもしれない。

この混線を避けるには、判断を二つに分ける必要がある。リスクの緊急度は、調査や封じ込めを今すぐ始めるべきかを示す。本番反映の準備状況は、修正を安全に適用できるだけの担当者、テスト、検証方法、対象範囲、ロールバックがそろっているかを示す。担当者が未定でも危険性は下がらない。それは単に、本番へ反映する条件が整っていないという意味である。

Tenableが2026年7月15日に発表した更新は、アプリケーションセキュリティの情報を、組織固有の実行環境や露出状況と結び付けて優先順位を考える文脈を示している。CISAのSSVCも、脆弱性の状態に応じて判断を進める方法を提供する。ただし、外部情報だけでは自社サービスの実行経路や公開範囲までは証明できない。以下の証拠カードは、そうした情報を手掛かりにしつつ、自社の技術的影響、資産の重要度、防御策、本番反映の条件を加えて判断するためのローカルな運用手順である。

点数ではなく、証拠の組み合わせで行動を決める

調査の起点は、既知の悪用や進行中の攻撃である。該当する場合、実行経路の確認がすべて終わるまで対応を待つべきではない。人へ直ちにエスカレーションし、必要に応じて通信制限、入口の停止、隔離といった可逆的な封じ込めを検討する。

悪用が確認されていない場合は、問題箇所が実際の処理から呼び出されるかを調べる。呼び出し関係、実行トレース、再現テストが主な根拠になる。さらに、公開入口、入力元、認証、権限、ネットワーク経路を確認し、外部利用者や低権限アカウントなどの低信頼な入力がその処理へ届くかを見極める。ここに技術的影響、資産の重要度、既存の防御策を重ねて、次の行動を選ぶ。

証拠の状態	次の行動
既知の悪用または進行中の攻撃がある。もしくは、問題箇所まで処理が到達し、低信頼入力にも露出しており、重大な技術的影響または重要資産への影響が見込まれる。重要資産や悪用兆候があり、重大な証拠不足そのものが人への即時エスカレーションを必要とする場合も含む	即時対応。人へ直ちに報告し、必要なら可逆的な封じ込めを行う。修正、本番反映、検証の担当者も割り当てる。ただし、この判定だけで本番反映を承認してはならない。
到達可能性、露出、影響、資産の重要度、防御策のいずれかが不明で、即時対応の条件には該当しない	期限付き検証。結論を変え得る情報を特定し、確認方法、担当者、期限を記録する。AIは警告を終了せず、修正を自動反映しない。新しい証拠に応じて、人が対応レベルを引き上げる。
再現可能な証拠が、問題箇所へ到達しないこと、低信頼入力からの経路がないこと、または防御策が有効であることを示し、既知の悪用、進行中の攻撃、重大な露出もない	保留・監視。判断根拠と有効期限を保存し、構成、公開経路、権限、バージョン、防御策、悪用状況が変わった場合の再確認条件を定める。

KEVは、実際の悪用が確認された脆弱性を米国CISAがまとめた一覧である。CSAFは、セキュリティ勧告を機械処理可能な形で交換するための共通形式である。VEXは、特定の製品や構成が脆弱性の影響を受けるかどうか、その状態と理由を伝える。いずれも調査に役立つ信号だが、自社環境で問題箇所まで処理が届くことや、低信頼入力に露出していることを単独で証明するものではない。

一枚のカードに、二つの結論を残す

証拠カードは脆弱性一件につき一枚とする。識別子、対象サービス、部品とバージョン、検出日時、スキャンツールの主張を最初に記録する。その後で、悪用や攻撃の兆候、到達可能性、露出、技術的影響、資産の重要度、防御策について、確認済みの事実と未確認事項を分けて置く。

カードの結論は一つにまとめない。リスクについては「即時対応」「期限付き検証」「保留・監視」のいずれかを選ぶ。本番反映については別欄を設ける。担当者、テスト結果、検証方法、対象範囲、ロールバックがすべてそろっていれば、人によるレビュー準備完了（READY_FOR_HUMAN_REVIEW）である。これは人のレビューに渡せる状態を意味するだけで、本番反映の承認ではない。必要条件の欠落が判明している場合は未準備（NOT_READY）、情報不足で判定できない場合は**要確認（TO_CONFIRM）**とする。

この分離により、「危険なので今すぐ対応を始めるが、修正はまだ本番へ出せない」という状態を正確に表せる。たとえば悪用が確認されている一方、検証方法やロールバックが欠けているなら、記録は「即時対応／未準備」となる。封じ込めや調査は急ぐが、検証を飛ばした本番反映は認めないという判断である。

AIに任せられるのは、証拠の整理、欠けている項目の抽出、判定候補の下書きまでである。GitHub Docsも、セキュリティおよび品質に関するAI機能では、利用者が制約を理解して出力を確認する必要があるとしている。リスク結果の確定、警告の終了、修正の承認、本番反映は人が行う。役割分担を先に整えるなら、AIが脆弱性を整理しても、リリース判断は人が持つが参考になる。コンテナスキャンの警告が多すぎる場合は、Dockerスキャナーの警告から、実際にイメージへ影響するものを見分ける方法も併用できる。

五件だけ選び、運用の詰まりを見つける

最初から全警告を移行する必要はない。同じサービスから五件を選び、高得点だが到達しない可能性があるもの、点数は中程度でも公開入口に関係するもの、悪用兆候があるもの、担当者や検証情報が欠けているものを意図的に混ぜる。

サービス担当者とセキュリティ担当者が証拠を確認し、まずリスク結果を決める。その後、本番反映に必要な五つの条件を別に確認する。従来のスコア順と並べ比べれば、本当に先に扱うべき項目が入れ替わるか、どの証拠が繰り返し不足するかが見えてくる。

判断できないときに、AIへ長い要約を書かせても状況は改善しない。結論を変える情報は何か、その確認方法、担当者、期限をカードへ戻すべきである。五枚を試した後は、頻繁に欠けた情報をサービスの引き継ぎ、エンドポイント追加、構成変更の工程で収集できるようにする。

AI整理カード

現在アクセス可能なリポジトリ、プロジェクト、脆弱性スキャン結果、CI 履歴、作業環境を起点にする。最初に行うのは読み取り専用の調査だけであり、ファイル、設定、チケット、アラート、ジョブの状態は変更しない。ソース、依存関係の manifest／lockfile、検査レポート、ログ、バージョン情報を確認し、脆弱性対応上の具体的な問題または改善余地を一つだけ選ぶ。利用者に資料の整理や貼り付けを先に求めてはならない。

まず「確認できた事実」と「そこからの推論」を分ける。事実には、ファイルパスと行番号、レポートの検出項目、CI job／log の場所、または実行した読み取り専用コマンドと要点となる出力を直接の根拠として添える。推論には未検証の前提と確認方法を記す。コンポーネント、該当バージョン、環境、露出条件を根拠から確定できない場合は「要確認」とし、補完や憶測はしない。

そのうえで、単一の問題を扱う証拠カードを作る。リスク判断は「即時対応」「期限付き検証」「保留・監視」のいずれか一つとし、選択理由を証拠に結び付ける。デプロイ準備度は別項目として READY_FOR_HUMAN_REVIEW、NOT_READY、TO_CONFIRM のいずれか一つを記載する。両者を混同してはならない。

最後に人間が確認すべき判断点を明示する。エスカレーション、アラート終了、修正承認、merge、deploy、release は人間の決定として残し、自動実行しない。プロジェクトにも関連証拠にもアクセスできない場合に限り、調査開始に必要なアクセスまたは状況について焦点を絞った質問を一つだけ行い、そこで止める。

末尾には、人間の権限を侵さず今すぐ実行できる次の行動を一つだけ、具体的に記す。