コンテナとWebアプリケーションの脆弱性に優先順位を付ける7つのヒント

バックログにあるWebアプリケーションの脆弱性をすべて修正するのは現実的ではないため、優先順位を付ける必要があります。優先順位付けによって、組織にとって最も重要な問題に集中でき、限られた時間とリソースを最大限に活用して、セキュリティへの効果を高められます。

脆弱性の優先順位付けは、どこから始めればよいのでしょうか？

優先順位付けにはさまざまな方法があり、どの方法を選ぶかは、実施しているセキュリティアプローチによって異なります。優先順位付けを構成するさまざまな要素を理解するために、Webアプリケーションの脆弱性の優先順位付けで広く使われているツールをいくつかご紹介します。優先順位付けを進める際にお役立てください。

1. CWE

CWEとは？

CWEはCommon Weakness Enumeration（共通脆弱性タイプ一覧）の略称で、ソフトウェアやハードウェアの弱点を分類したオンライン用語集です。たとえば、CWE-20（入力値の検証）、CWE-125（境界外読み取り）、CWE-79（XSS）、CWE-200（情報漏えい／開示）などがあります。

MITREが管理するCWEは、ソフトウェアセキュリティの問題をできるだけ早く効果的に特定、発見、解決するための手段として提供されています。また、Webアプリケーションの脆弱性の優先順位付けにも、次のような方法で活用できます。

• 時間がなく、コード内で見つかった脆弱性を詳しく調査できない場合は、コミュニティが特に重要と判断したCWEの修正を優先するための出発点として、CWE Top 25のリストを活用しましょう。

• 影響度に基づいて優先順位を付けるには、CWEを活用しましょう。CWEの各項目には、その弱点がもたらす技術的な影響に関する情報が含まれています。すべてを修正しようとするのではなく、この情報を使って、自組織にとってより危険なCWEに集中しましょう。

• CWSSとCWRAFを活用しましょう。どちらもCWEのスコアリングシステムで、ビジネスとの関連性に基づいて優先順位を付けられます。

2. CVSS／深刻度

優先順位付けに最も広く使われているのが、業界標準のCommon Vulnerability Scoring System（CVSS）です。脆弱性の深刻度を評価するために使われます。Webアプリケーションの脆弱性がどれだけ悪用されやすいか、悪用に成功した場合にどの程度の影響があるかに基づき、0〜10のスコアが割り当てられます。10が最も深刻なスコアです。

NVDによると、CVSS（v3）の基本スコアが0.0〜3.9の場合は「低」、4.0〜6.9の場合は「中」、7.0〜8.9の場合は「高」、9.0〜10.0の場合は「緊急」と評価されます。

CVSSは有効な出発点ですが、脆弱性がもたらすリスクを十分に正確に示すものではないことを念頭に置いてください。CVSSの公式ドキュメントにも記載されているように、「CVSSは脆弱性の深刻度を測定するために設計されており、リスク評価に単独で使用すべきではありません。CVSS基本スコアは、環境のコンテキスト分析や、時間とともに変化する可能性のある属性によって補完する必要があります。」

3. 悪用可能性

脆弱性が組織にもたらす実際のリスクを判断する方法の一つは、どれだけ簡単に悪用できるかを理解することです。ハッカーによる脆弱性の悪用を非常に容易にする要因の一つが、エクスプロイトコードの存在です。このようなコードが公開されると、その脆弱性は「実際に悪用されている」と見なされます。

バックログにある問題について、実際に悪用されているかどうかを把握すれば、リスクの高い問題に絞って対応できます。公開されたエクスプロイトの種類を区別すれば、さらに対象を絞れます。成熟していて公開済みで実用的なエクスプロイトと、学術的・理論的なものとでは、リスクが異なります。優先順位付けにおける悪用可能性の重要性については、こちらをご覧ください。

4. 到達可能性

開発者はオープンソースコンポーネント全体をコードベースに取り込む一方、アプリケーションのロジックで実際に使うのは、その一部だけということがあります。そのため、一部の脆弱性はアプリケーションの実行経路で呼び出されず、リスクが低いため優先度を下げられる場合があります。

AppSecツールでこの情報を確認できる場合は、緊急性の高い問題に集中するために活用しましょう。アプリケーションから呼び出されない関数にある深刻度の高い脆弱性よりも、実行経路上にありリスクが高い中程度の脆弱性を優先するほうが、はるかに効果的です。

次の相補的なアプローチのいずれか、または両方を使って優先順位を付けられます。

• ソースコードの静的解析による到達可能性の判定

• 脆弱性を含むコードが実行時に実際に呼び出されているかを判断する

到達しない脆弱性が重要ではなく、無視してよいという意味ではないことに注意してください。特に深刻度の高いものは、トリアージして修正する必要があります。ただし、到達可能性を調べることで、重要な問題と緊急の問題をより適切に見分けられます。

5. 経過期間

優先順位を決める際は、脆弱性が発見されてからの期間も考慮しましょう。たとえば、新しい脆弱性ほど、修正策がまだ提供されていない可能性があります。また、ハッカーは新しく注目を集める脆弱性に引き寄せられる傾向があり、その分リスクも高まります。たとえば、SnykのPriority Scoreを支えるアルゴリズムでは、まさにこの考え方に基づき、最終スコアに経過期間を反映しています。

6. 修正のしやすさ

セキュリティ対策の一つとして、一定期間内にできるだけ多くの問題を修正する方法があります。スピードが重要な場合は、最も簡単で、短時間かつ低コストで修正できる問題を優先することを検討しましょう。

そのために、次の点を確認してください。

• マイナーアップグレードで脆弱性を修正できますか？

• 脆弱性に対するパッチは提供されていますか？

• 脆弱なコンポーネントを簡単に置き換えられますか？

7. 自動化

組織内のさまざまなプロジェクトにまたがる数百、場合によっては数千もの問題に優先順位を付けたり、優先度を下げたりするには、自動化が欠かせません。セキュリティツールにその機能がある場合は、ポリシーを使って修正対応の優先順位を決める基準を自動的に設定しましょう。

たとえば、特定のCWEに該当するすべての脆弱性の深刻度を上げたり、既知のエクスプロイトがない問題の深刻度を自動的に下げたりできます。

こうした判断はビジネスによって異なり、組織やチームごとに変わります。一方で、ポリシーによる自動化と細かな制御は、あらゆる優先順位付け戦略に欠かせません。

Webアプリケーションの脆弱性を効果的に優先順位付けするメリット

効果的な優先順位付けによって、組織に最大のリスクをもたらす脆弱性に集中できます。時間と労力を有効に活用し、最終的にはセキュリティ態勢全体を強化できます。

ただし、ここまで見てきたように、適切な優先順位付けにはCVSSだけでは不十分です。より多くの、そしてより深いコンテキストを提供するソリューションが必要です。ツールが使いやすく、開発者にとって扱いやすいほど、開発者に定着しやすくなります。これは、優先順位付けと修正対応を成功させるうえで重要です。これこそが、Snykが提供する価値です。