2026年に報告されたCVEは、1日あたり前年比131%増加しています。

依存関係

到達可能性分析

到達可能性分析は、コードが依存関係内の脆弱な関数を実際に呼び出せるかどうかを確認します。パッケージに欠陥があっても、アプリケーションがそこに一切触れないことがあります。到達可能性分析はそうした検出結果の優先度を下げ、チームが悪用され得るものに取り組めるようにします。

更新日

なぜ必要なのか

SCAスキャンは、パッケージのバージョンをアドバイザリと照合します。あるバージョンに欠陥があることはわかっても、アプリケーションがその欠陥のある部分を使っているかどうかはわかりません。数百の関数と1つの脆弱なパーサーを持つライブラリは、そのパーサーを呼び出しているかどうかにかかわらず同じように報告されます。大規模な依存関係ツリー全体では、それが積み重なり、誰にも片付けられないバックログになります。

到達可能性分析の仕組み

  1. 脆弱なコードを特定する。ツールは、脆弱性がどの関数にあるかを知る必要があります。アドバイザリには記載されていないことが多いため、ベンダーは独自のデータを維持しています。
  2. コールグラフを構築する。自社のコードから依存関係の奥まで、どの関数がどの関数を呼び出すかをマッピングします。
  3. 経路を探す。自社のコードから脆弱な関数へ至る呼び出しの連鎖があれば、その検出結果は到達可能です。なければ到達不能とマークされ、優先度が下がります。

到達可能性のレベル

レベル 答える問い トレードオフ
依存関係 そもそもパッケージがインポートされているか 低コストだが、除外できるのは未使用の依存関係のみ
関数 呼び出し経路が脆弱な関数に到達できるか 一般的な目標。コールグラフと関数単位の脆弱性データが必要
ランタイム このコードは本番環境で読み込まれたか、実行されたか 実際のトラフィックに基づくエビデンスだが、観測中に実行されたものに限られる

実際の攻撃には経路だけでは足りません。入力が、欠陥を引き起こす形で関数に届く必要があり、それを判断できるツールはほとんどありません。

到達可能性分析の限界

  • 到達不能は安全という意味ではありません。ツールが経路を見つけられなかったという意味です。リフレクション、動的インポート、プラグインの読み込みは、静的解析では見えない経路を生み出すことがあります。
  • 言語ごとの対応範囲が異なります。静的にコンパイルされる言語は動的な言語よりも追跡しやすく、関数レベルの分析をどのエコシステムで提供するかはツールによって異なります。
  • 脆弱性データは不完全です。アドバイザリを関数に対応付けた人がいなければ、ツールには探す対象がありません。
  • コードとともに変わります。今日到達不能な検出結果が、次のリリース後には到達可能になることがあるため、再確認が必要です。
  • 順位付けできるのは特定されたものだけです。スキャナーが見つけられなかったコンポーネントは分析できません。完全なインベントリがなければ、到達可能性分析は全体像の一部を並べ替えるにすぎません。

安全な使い方

  • 対応を見送るためではなく、順番を決めるために使う。到達可能な検出結果を先に修正し、残りはクローズせずに計画に組み込みます。
  • 実際の悪用情報より優先させない。CISAのKEVカタログに掲載されている検出結果や、EPSSスコアが高い検出結果は、到達不能とマークされていても人が判断すべきです。
  • インターネットに公開されたサービスでは慎重に。攻撃者が直接到達できる場所ほど、判断を誤ったときの代償が大きくなります。
  • 判断の理由を記録する。検出結果が該当しないと判断した場合は、VEXステートメントでその判断を残し、理由を顧客に伝えられます。

到達可能性が深刻度、エクスプロイトのデータ、ビジネス上の文脈とどう組み合わさるかは、脆弱性の優先順位付けの方法をご覧ください。

到達可能性分析を提供するツール

Snyk、Endor Labs、Mend、Checkmarx、Semgrep、Aikidoなど、多くの商用SCAツールが提供しており、その深さは言語によって異なります。Goのgovulncheckは、1つのエコシステム向けの無料の例です。それぞれの対象範囲はおすすめのSCAツールの比較をご覧ください。

CRACIの役割

CRACIは到達可能性分析を提供していません。CRACIが担うのはその前段階、つまりそもそもビルドに何が含まれているかを把握することです。CRACIはGitHub Actionsのランナーで、ロックファイルスキャナーが見落とす隠れた依存関係も含め、各ジョブが取得したすべてのパッケージを記録し、新しい脆弱性が公開されるたびに、出荷したもののSBOMを再評価し続けます。到達可能性が最優先事項であれば、それに特化したツールをCRACIと併用してください。SCAツールと並べたときのCRACIの位置付けをご覧ください。

到達可能性分析:よくあるご質問

SCAにおける到達可能性分析とは何ですか?

コードが依存関係内の脆弱な関数を実際に呼び出せるかどうかを確認し、自社のコードから経路のない検出結果の優先度を下げられるようにするものです。

到達可能性分析は正確ですか?

有用ですが、証明にはなりません。到達可能な検出結果には実際の経路がありますが、到達不能というのはツールが経路を見つけられなかったという意味にすぎません。リフレクション、動的読み込み、脆弱性データの欠落はいずれも経路を隠すことがあります。

到達不能な脆弱性は無視してもよいですか?

一律に無視するのは避けてください。到達可能な検出結果の後に対応を計画し、コード変更の後に再確認し、実際に悪用されているものやインターネットに公開されたサービスで動いているものには特に注意を払ってください。

到達可能性と悪用可能性の違いは何ですか?

到達可能性は、コードが脆弱な関数にたどり着けるかを問います。悪用可能性は、攻撃者がその経路を使って害を及ぼせるかを問います。欠陥が到達可能でも、自社の環境では悪用できないことがあります。

到達可能性分析でアラートは減りますか?

はい、それが主な目的です。どれだけ減るかは、言語、ツール、そして各依存関係をコードがどれだけ使っているかによります。

ビルドの全体像から始める

何を修正すべきかを決める前に、GitHub Actionsのジョブが実際に取り込んだすべてのパッケージを確認してください。

デモを予約