リーチャビリティを超えて、本当に重要な問題を優先する

最新のアプリケーションの多くは、相当数のオープンソースパッケージ、ライブラリ、フレームワークで構成されています。実際、最新のアプリケーションではソースコードの少なくとも80%がオープンソースだと推定されています。アプリケーションの構築に汎用コンポーネントを大きく頼るだけでなく、開発チームはコミュニティから提供されたコンテナベースイメージを使って、こうしたアプリやサービスをデプロイすることもよくあります。さらに、AIコーディングアシスタントなどのサードパーティリソースを活用して自社コードを生成し、ソフトウェアサプライチェーンをいっそう加速させています。

オープンソースライブラリ、生成AI、コンテナの利用が増え続けることで、新たなライセンス上およびセキュリティ上の懸念が生じています。2023年だけで、約29K件の新たな脆弱性が発見されました（2024年もすでに28K件を超えています）。過去と同じ傾向が続くなら、新たに発見された脆弱性の半数以上が高または重大な深刻度となるでしょう。つまり、アプリケーション、ひいては組織全体にとって最大級のリスクの一部は、自社で制御できないコンポーネントに起因します。

今日のオープンソースセキュリティが抱える課題

アプリケーション内のオープンソースの脆弱性をすべて見つけ、優先順位を付けて修正するのは現実的ではありません。サードパーティ依存関係にある高深刻度の脆弱性だけを修正する場合でも、容易ではありません。新たに発見された脆弱性だけでなく、コードベースにある脆弱性の未対応分にも対処する必要があるからです。こうした未対応分が生じる背景はさまざまです。引き継いだものかもしれませんし、オープンソースの脆弱性を調べ始めるずっと前に実装されたプロジェクトに残っているのかもしれません。

小規模なプロジェクトでも、数十の直接依存関係（依存関係マニフェストで明示的に定義されるもの）に、数百件の脆弱性が存在する場合があります。さらに、直接依存関係の動作に必要なライブラリである、間接的な依存関係（「推移的依存関係」）はもっと多いでしょう。これらすべてを組織内のプロジェクト数分だけ考えると、リストは膨大な長さになります。

静的な優先順位付け手法だけでは不十分

多くの企業は、NVD/CVSSの深刻度などの静的なリスク要因を使って、この長い脆弱性リストのトリアージを始め、最初に修正するものの優先順位を付けています。しかし、ある時点のリスクを捉えた情報だけでは、正確で効果的な優先順位付けに欠かせない多くの要素を見落としてしまいます。

EPSS（Exploit Prediction Scoring System：悪用予測スコアリングシステム）などの新しいリスク要因は、脆弱性に関する情報をより多く取り入れようとしますが、より広範なアプリケーションやビジネスのコンテキストといった重要な詳細は依然として考慮されません。他の静的なリスク要因と同様、EPSSもアプリケーションではなく、個々の問題に焦点を絞った限定的な評価にとどまります。EPSSが評価する問題は個別のCVEに関するものであり、組織全体に最も大きな影響を与えるものを評価するわけではありません。

静的な優先順位付け手法を強化し、どの脆弱性を先に修正すべきかをより適切に判断するために、多くの企業がリーチャビリティを活用しています。静的リーチャビリティでは、脆弱性の定義を確認し、特定のバージョンのライブラリ内でその脆弱性が存在する場所に関する情報を取得したうえで、自社コードから脆弱性が存在すると考えられる関数までの呼び出し経路があるかどうかを判断します。チームは、リーチャビリティデータや高いCVSSスコアまたはEPSSスコアなど、さまざまな静的シグナルを組み合わせて、どの修正を優先するかを判断できます。

静的リーチャビリティは優先順位付けに役立つ一方で、見落としが生じることもあります。たとえば、脆弱な関数を呼び出すコードパスの特定には役立つかもしれませんが、その逆、つまり何かに到達できないことを確実に判断することはできません。また、静的リーチャビリティ分析に必要な情報が含まれていない脆弱性もあります。一方、オープンソースパッケージ内の脆弱な関数を特定する手法もあります。たとえばSnykは、AIを活用したソリューションで修正コミットを評価し、脆弱な関数を算出しています。

最終的に、静的リーチャビリティをCVSS/EPSSと組み合わせることで優先順位付けは改善しますが、重要なコンテキスト、すなわち特定のアーティファクトがビジネスにとってどれほど重要かを取り入れることで、さらに強化できます。そのため、ビジネスに対する実際のリスクに基づいて脆弱性を正確に優先順位付けするには、静的リーチャビリティ以外のコンテキスト要因も考慮する必要があります。

組織には、リスクの優先順位付けに包括的なアプローチが必要

脆弱性について覚えておきたいのは、深刻度が高く到達可能だからといって、悪用可能だとは限らないということです。

この考え方を掘り下げてみましょう。2つの脆弱性があるとします。1つは、社内の開発用サンドボックスで実行されている「到達可能」な重大度の脆弱性。もう1つは、本番環境で実行されている、リーチャビリティデータのない中程度の深刻度の脆弱性です。どちらを先に修正すべきでしょうか？本番環境の中程度の深刻度の脆弱性に、簡単に実行できる、広く知られたエクスプロイトがあり、インターネットに公開されたエッジのコンテナに存在するとしたらどうでしょう？中程度の深刻度の脆弱性を先に直すのが明白に思えるかもしれませんが、静的シグナルだけで判断すると、実際にはサンドボックスの脆弱性のほうが優先度が高いと評価される可能性があります。

この例からわかるように、静的リーチャビリティだけでは全体像を把握できないことがよくあります。静的リーチャビリティは脆弱性の優先順位付けに役立つ知見を提供しますが、チームが全体的なリスクを管理することを可能にするものではありません。重大度の高い脆弱性を大量に修正すれば、数字の上では見栄えがよいかもしれません。しかし、本当の効果は、ビジネスと収益に最も大きな損害をもたらす可能性のある脆弱性を修正することにあります。

静的リーチャビリティだけではわからないことを補う、追加のシグナルをいくつかご紹介します。

• その脆弱性は、サービスが実行されているオペレーティングシステムに実際に該当しますか？

• そのアプリはビジネスにとって重要ですか？具体的にどのような役割を果たし、ビジネスの主要な機能とどのように関係していますか？

• デプロイされていますか？デプロイされている場合、どこにデプロイされていますか？外部に公開されている、または外部からアクセス可能ですか？パッケージは読み込まれていますか？

• その脆弱性が存在するサービスは、機密データにアクセスできますか？

Snykによるコンテキストを考慮したリスクベースの優先順位付け

企業がすべてのオープンソースの脆弱性、あるいは深刻度が高いまたは重大な脆弱性をすべて解消することはできないため、セキュリティ上の問題を正しく優先順位付けすることが重要です。Snykは、組織がソフトウェアの脆弱性を見つけて修正できるよう支援するだけでなく、企業に対する現実世界のリスクに基づいて修正の優先順位を付けることも支援します。Snykのソリューションは、次の方法で組織のアプリケーションセキュリティプロセスを強化します。

• リスクベースの優先順位付けにより、エクスプロイトが発生する可能性と、発生した場合の影響を明確に把握できます。

• コードからクラウドまでのリーチャビリティでは、コードと脆弱な関数を分析する静的リーチャビリティと、アプリケーションのデプロイ後／実行時の環境を調べる動的リーチャビリティの両方を扱います。AIを活用し、人間のセキュリティ専門家が検証することで、精度とカバレッジを高めています。

• SCM、開発者ポータル、CMDBなどから得られるアプリケーションのコンテキストを活用します。こうした詳細なコンテキストにより、コードの所有者、リポジトリの更新状況、その他の要因に基づいて、対処すべき脆弱性をさらに絞り込めます。

• エンタープライズに適した柔軟性を備え、独自のセキュリティガイドラインやコンプライアンスガイドラインをSnykのソリューションに直接統合できます。

• 包括的なリスクスコアは、AppSecの取り組みに簡単に活用できます。このスコアを使えば、環境全体のSCAの問題に優先順位を付けたり、特定のリスク要因（静的リーチャビリティを含む）が及ぼす影響を掘り下げて把握したりできます。

オンデマンドデモをご覧いただき、Snyk AppRiskの仕組みをご確認ください。