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