メトリックを使用した Dependabot alerts の優先順位付け
アプリケーション セキュリティ (AppSec) マネージャーは、Dependabot alerts の大量発生のため、どの脆弱性に最初に対処すればよいか決めるのに苦労することがよくあります。 Dependabot メトリックによって提供される貴重な分析情報は、効率的にアラートの優先順位を付けて、重大なセキュリティの問題を迅速に解決するのに役立ちます。 ユーザーは、最も影響の大きい脆弱性にリソースを集中させ、情報に基づいた意思決定を行うことができます。 このアプローチにより、organization のセキュリティ態勢が強化され、脆弱性管理が効率化されます。
Dependabot メトリックについて
Dependabot メトリックは、依存関係で検出された脆弱性についての詳細な情報を提供します。 主要指標には、以下が含まれます。
- 重大度: 脆弱性の潜在的な影響 (低、中、高、重大など) を示します。
- 悪用可能性: どれくらい簡単に脆弱性を悪用できるかを評価します。
- 依存関係の関係性: 直接的と推移的な依存関係を区別します。
- 依存関係のスコープ: 実行時と開発時の依存関係を区別します。 脆弱なコードがアプリケーションで実際に使われているかどうかを判断します。
- 過去 30 日間の対応済みアラート (Dependabot で修正されたアラート、手動で無視したアラート、自動的に無視されたアラートの数を含む): アラートの解決の進行状況を追跡します。 GitHub Code Security が脆弱性の早期検出にどのように役立つかを示します。
- リポジトリごとの未対応アラートの合計数と、重大度と悪用可能性のデータを示す表: リポジトリ レベルでさらに詳しく調べることができます。
これらのメトリックについて詳しくは、「Dependabot アラートのメトリックの表示」をご覧ください。
また、使用できる個々のフィルターの組み合わせである複雑なフィルターを指定することもできます。 フィルターについて詳しくは、Dependabot ダッシュボード ビューのフィルターに関する記事をご覧ください。
アラートに優先順位を付ける手順
以下の初期手順は、organization を最も危険にする Dependabot alerts を特定するのに役立ち、修復で重点を置くアラートを開発者に伝えることができます。
1.Organization のニーズに合わせてフィルターの順序を調整する
[Alert prioritization] グラフでフィルターの既定の順序をカスタマイズし、organization に固有のリスク プロファイル、ビジネスの優先順位、コンプライアンス要件を確実に反映させることができます。 「Dependabot アラートのメトリックの表示」を参照してください。
2.クリティカルで重大度の高いアラートに焦点を当てる
最初に、severity-critical または severity-high フィルターを使って、重大度が最も高いアラートを識別します。 これらの脆弱性は最大のリスクになるので、多くの場合、コンプライアンス標準によって優先されます。 その場合、
3.悪用可能性と到達可能性を評価する
コードベースで悪用される可能性が最も高い脆弱性を優先します。 悪用される可能性が最も高いアラートを特定するには、値に関連付けられている epss_percentage フィルターを使用できます (例: epss_percentage>=0.10)。
4. 依存関係のスコープと関係性を確認する
通常、直接的な依存関係は更新が容易であり、アプリケーション’セキュリティにいっそう大きな影響を与える可能性があります。 可能な場合は、推移的な依存関係より先にこれらを解決することをお勧めします。
relationship:direct フィルターを使ってアラートをフィルター処理すると、npm などのサポートされているエコシステムに対する直接的な依存関係での脆弱性を確認できます。
実行時の依存関係は、運用環境でアプリケーションによって使われます。 この種の依存関係を更新すると、エンド ユーザーまたはシステムに直接影響を与えるセキュリティの脆弱性、バグ修正、パフォーマンスの向上に対処できます。 一方、開発時の依存関係は、開発、テスト、またはビルドのプロセス中にのみ使われます。 重要ですが、これらの依存関係の問題は、通常、実行中のアプリケーションまたはそのユーザーに影響を与えることはありません。
scope:runtime または scope:development フィルターを使って、それぞれ実行時または開発時の依存関係に関するアラートのみを表示できます。
5.アラートの経過時間を考慮する
古いアラートは、長期的なリスクを示している可能性があります。 セキュリティ負債の蓄積を防ぐため、経過時間の長いアラートを定期的に確認して対応します。 たとえば、優先する必要があるアラートが、特定のリポジトリに他のリポジトリよりも多くある場合は、次のようにすることができます。
- リポジトリごとのテーブルでリポジトリ名をクリックし、そのリポジトリのアラートのみを表示します。
- [Sort] ドロップダウン リストの [Older] フィルターと、他の並べ替え条件を使って、条件を満たすアラートが経過時間順になるように表示を調整します。
6.自動化を活用する
Dependabot の自動 pull request を使って、脆弱性をすばやく修復します。 これらの更新を CI/CD パイプラインに統合して、より迅速な解決と効率の向上を実現します。
ベスト プラクティス
- 重大度に基づいて脆弱性を解決するためのサービス レベル アグリーメント (SLA) を設けます。
- メトリックを定期的に監視して、傾向や繰り返される問題を明らかにします。
- 開発者と協力して、更新がタイムリーに行われるようにし、中断を最小限に抑えます。
- 決定事項を文書化して、透明性を提供し、将来の優先順位付けをサポートします。