コード、コンテナ、クラウドを横断する依存関係グラフがなければ、本当の脆弱性に気づかない

スーラジ・シャー

#依存関係

#SAST

#SCA

掲載日

2025年9月5日

最終更新日

2025年9月9日

アプリケーションは孤立した環境で動作するわけではありません。オープンソースパッケージ、コンテナ、クラウド管理リソース、VM、APIなどで構成されています。各要素には独自のセキュリティ対象領域とスキャナーが存在します：静的コード分析ツール（SAST）はソースコードの脆弱性を、ソフトウェア構成分析（SCA）ツールは依存関係を、クラウドセキュリティツールは設定を、コンテナスキャナーはイメージ内の既知のエクスプロイトをそれぞれスキャンします。

では、これら全てのスキャナーを導入すれば…安全ですよね？

まあ、そうとも言えます。確かに各レイヤーはスキャンされています。

しかし、その代償は？

なぜセキュリティスキャナーは誤検知であなたを圧倒するのか

スキャナーは、上流のAPIによって保護されていることを知らずに、コード内の脆弱な関数を警告する可能性があります。あるいは、コンテナ基盤レイヤーのCVEに関する危険を感知するかもしれませんが、実際のアプリケーションがそのコードパスに到達しないという事実には気づかないでしょう。同様に、クラウドスキャナーは、権限を超えたIAMロールをフラグ付けするかもしれませんが、それが本番データにアクセスできないステージングワークロードにのみリンクされていることに気づかない可能性があります。

その結果？チームは大量の孤立した発見情報に埋もれてしまいます。確かに技術的には正確ですが、問題が本当に危険かどうかを判断するための文脈がほとんどありません。
‍
あるいは、ある大企業のセキュリティエンジニアが最近こう言いました：「その脆弱性が私の『王冠の宝石』に影響するのか、それとも仮想ランチメニューに影響するのか、見分けられますか？」

単独の偽陽性や偽陰性もリスクではあるが、より大きなリスクは依存関係チェーンを見落とすことだ。このチェーンによって、一見無害な問題が実際の攻撃経路へと組み合わされるかどうか、あるいは一見有害に見える多くの問題が全く問題ではないかどうかが決まる。

そして、チームからいつもこう聞かされます：

「私たちは依存関係を制御していません。」

その理由は？サプライチェーンの管理が難しすぎるからです。オープンソースパッケージには間接的な依存関係が伴います。コンテナスキャンやクラウドネイティブツールを活用しても、ほとんどの組織は重要な要素を確信を持って特定できません。結果として、脆弱性を事後対応的に追いかける羽目になるのです。

アプリケーションセキュリティとクラウドセキュリティにおいて脆弱性のコンテキストが重要な理由

典型的なSASTやSCAツールは非常に単純で文字通りの見解を取る。

例えば、あるパッケージがCVEに登録されていることを検知すると、それを重大な問題としてフラグを立てます。

それは理論上はベストプラクティスに聞こえる。結局のところリスク回避的な方が良いと思うだろう。しかし実際には、それは単に誤った警報を引き起こすだけだ。なぜなら：

多くの場合、アプリケーションは脆弱な関数を呼び出していません
その関数は、直接触れたことのない推移的依存関係の中に埋もれている可能性がある
あるいは開発者専用で本番環境には決して移行されないインポートの背後にある

チームは「重大な」問題の過剰に詳細なリストを受け取り、何時間もかけてそれらを追跡する羽目になるが、結局それらが重大ですらないと気づくことになる。

同時に、実際に悪用される可能性のある経路は見過ごされるかもしれない。

コード、コンテナ、クラウドを横断した完全な依存関係グラフの構築

多くのスキャナがノイズの多い結果や不完全な結果しか提供しない理由は、明確性を確保するために必要な追加の文脈を欠いているためです。従来のツールは、ソースコード、オープンソースパッケージ、コンテナ、クラウドリソースといった各レイヤーを別個の問題として扱い、しばしば別々の製品で処理します。

つまり、それらを統合する単一の依存関係グラフが存在しないということです。相互依存関係の可視性がありません。つまり、重要でない問題については通知を受け取れますが、実際に重要な問題を見逃す可能性があります。

しかし可視性は文脈だけではない。一貫性が重要だ。パッケージ管理ツールはすべて、推移的脆弱性の管理方法を異にしている。

例えば：

JavaScriptのnpm/yarnは依存関係ツリーを提供し、ネストされたパッケージの上書きや固定を可能にします。
JavaのMavenでは予期しないライブラリバージョンが導入される可能性があり、リスクのあるトランジティブパッケージを排除するには追加の設定が必要となる。

統一されたグラフがなければ、チームはリリースした内容を把握するためだけに、さらにツールを追加することになる。

「直接インストールしていなければ問題ない」と考えるエンジニアもいるが、これが問題を悪化させる。脆弱性は複数のレイヤーの奥深くに潜んでいる。

では、チームは何をすべきでしょうか？

依存関係における誤検知を排除するための到達可能性分析の活用

真の到達可能性分析とは、「グラフ内に脆弱なパッケージが存在します」と単に警告するだけでなく、プラットフォームが以下の点を判断できることを意味します：

実際に脆弱な関数を呼び出す、または
ユーザー入力に晒された欠陥に関与している、または
インターネットからアクセス可能なコンテナ内で実行する

これらの質問すべてに対する答えが「いいえ」の場合、それを無視する。「はい」の場合、エスカレートする。

開発者依存関係や本番環境に展開されないテストパッケージの背後にある伝播型脆弱性をフィルタリングすることも重要です。これによりノイズを大幅に削減でき、誤検知が減り、開発者がソフトウェア構築に集中できる時間が増えます。

ほとんどのスキャナーは、パッケージがCVEに登録されているかどうかを確認するかもしれません。しかし、実際のコードが脆弱な関数を呼び出しているかどうか、インターネットに公開されたコンテナにバンドルされているかどうか、リスクのあるIAM設定のクラウドリソース上で実行されているかどうかを、すべて一元的に追跡できるものはごくわずかです。