本文の内容は、2025年3月4日に Matt Kim が投稿したブログ(https://sysdig.com/blog/smarter-vulnerability-management-with-in-use-prioritization/)を元に日本語に翻訳・再構成した内容となっております。
脆弱性管理は常に課題となってきましたが、今日のセキュリティ チームはこれまで以上にプレッシャーを感じています。毎月何千もの新しい CVEが報告されており、その膨大な量により、どこに焦点を当てるべきかがわかりにくくなっています。In-useの脆弱性での優先順位付けは、実行時にアクティブにロードされる脆弱性のみに焦点を当て、ノイズを排除する最も効果的な方法の 1 つです。
本当に重要なことに集中するために、セキュリティチームはリスクの優先順位をより適切に設定する必要があります。すべての重大な脆弱性を修正しようとするのではなく、チームはすぐに対処する必要があるわずかな部分に集中できます。
問題: クラウドにおける脆弱性が多すぎる
セキュリティ チームは、250,000 を超える既知の CVEにより、脆弱性に溺れています。スキャンするたびに新たな問題が発見され、実際の脅威とバックグラウンドノイズを区別することがますます困難になっています。優先順位付けに対するより戦略的なアプローチがなければ、これらの脆弱性を管理することは不可能なタスクになります。
多くの企業は、開発の早い段階で問題を検出することで脆弱性管理を簡素化するために、シフトレフトセキュリティを採用しています。設計、コード コミット、ビルド、デプロイメントの各段階でスキャンが行われるクラウド環境では、同じ脆弱性が複数回フラグ付けされることがあり、開発が遅れる可能性があります。組織が優位に立つには、リスクを明確に把握する必要がありますが、セキュリティと高速リリース サイクルのバランスを取ることは常に困難です。
一方、開発者は、実際に修正する必要がある脆弱性を把握しようと、数え切れないほどの脆弱性のリストを整理するのに追われています。セキュリティチームは、開発者にすべてのパッチ適用を依頼することはできないと認識しています。しかし、適切なコンテキストがなければ、脆弱性管理によってリリースが遅れ、重大なリスクが未解決のままになることがよくあります。その結果、アラート疲れが発生し、悪用される可能性のない脆弱性を修正するための労力が無駄になります。
従来の優先順位付けフレームワークが不十分な理由
多くの組織は、まず重大度スコアを使用して脆弱性の優先順位を決定し、「重大」および「高」重大度の問題をすべて修正すればリスクが軽減されると想定します。これは論理的なアプローチのように見えますが、効果的に拡張できません。重大度が中程度および低度の脆弱性を除外した後でも、チームには現実的に対処できる以上の問題が残ります。
本当の問題は、たとえすべての脆弱性が「重大」な重大度であっても、すべての脆弱性が同じように危険であるわけではないということです。重大度だけではリスクは決まりません。一部の重大な脆弱性は、実際には本番環境で使用されていないパッケージに存在する可能性があり、攻撃者が悪用することはできません。一方、実行時にアクティブに露出する重大度の低い脆弱性は、攻撃者に侵入口を提供する可能性があります。これらの脆弱性に関する適切なコンテキストがなければ、重大度スコアのみに頼ると、チームが誤った結論を導き出す可能性があります。
解決策: In-useの脆弱性での優先順位付け
実際のリスクに焦点を当てるより効果的な方法は、In-useの脆弱性での優先順位付けです。つまり、本番環境でアクティブに実行されているパッケージの脆弱性を特定します。これらのパッケージだけが悪用される可能性があるからです。このアプローチでは、ランタイムインサイトを活用して不要なノイズを除外することで、脆弱性の優先順位付けにおける推測を排除し、チームが最も効果的な場所に修復作業を集中できるようにします。
Sysdig の脆弱性管理ソリューションにより、ユーザーは 1 回のクリックで In-useの脆弱性を特定できます。そこから、チームは追加のフィルターを使用して焦点をさらに絞り込むことができます。既知のエクスプロイトのある脆弱性を優先して、積極的に標的とされている脅威がリストの上位に表示されるようにすることができます。また、修正可能な脆弱性をフィルター処理して、セキュリティチームが実際に修正できる問題に時間を費やせるようにすることもできます。
In-useの優先順位付けの力により、セキュリティチームは対処する必要のある脆弱性の数を大幅に削減できます。実行時に読み込まれるパッケージ内の脆弱性を分離することで、セキュリティ チームは対応範囲をバックログのごく一部にまで削減でき、場合によっては 95% 以上削減できます。
セキュリティチームは、開発者に膨大な脆弱性のリストを渡す代わりに、的を絞った実用的なリストを提供できます。これにより、開発者はイノベーションを遅らせることなく、最も重大なリスクを修正できます。
まとめ
すべての脆弱性を修正しようとするのは非現実的であるだけでなく、時間とリソースの膨大な浪費にもなります。よりスマートな優先順位付けの方法がなければ、セキュリティ チームと開発者は修復作業の終わりのないサイクルにはまり込み、大きなリスクではない脆弱性をふるいにかけるうちに疲れ果ててしまいます。
In-useの脆弱性での優先順位付けは、こうしたノイズを排除するのに役立ちます。ランタイムインテリジェンスを使用して悪用不可能な脆弱性を除外することで、セキュリティチームは不要な作業を排除し、開発者の疲労を軽減し、脆弱性をより迅速に修正できるため、開発を妨げることなくセキュリティを強化できます。
