{"meta":{"title":"使用指标确定 Dependabot 警报的优先级","intro":"你可通过分析提供的指标，在组织中优先处理 Dependabot alerts。 使用此方法，可以告知开发人员首先关注最重要的漏洞。","product":"安全性和代码质量","breadcrumbs":[{"href":"/zh/code-security","title":"安全性和代码质量"},{"href":"/zh/code-security/tutorials","title":"Tutorials"},{"href":"/zh/code-security/tutorials/manage-security-alerts","title":"管理安全警报"},{"href":"/zh/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\n应用程序安全（AppSec）经理经常面临大量 Dependabot alerts问题，因此确定要首先解决哪些漏洞具有挑战性。\nDependabot 指标提供了有价值的见解，有助于有效地确定警报的优先级，确保及时解决关键安全问题。 用户可以做出明智的决策，集中资源解决影响最大的漏洞。 此方法增强了组织的安全态势，并简化了漏洞管理。\n\n## 了解 Dependabot 指标\n\n```\n          Dependabot 指标提供有关依赖项中检测到的漏洞的详细信息。 关键指标包括：\n```\n\n* 严重性\\*\\*\\*\\*：指示漏洞的潜在影响（例如，低、中、高、严重）。\n* 可利用性\\*\\*\\*\\*：评估某个漏洞可被利用的可能性。\n* 依赖关系\\*\\*\\*\\*：区分直接依赖项和传递性依赖项。\n* 依赖项范围\\*\\*\\*\\*：区分运行时依赖性和开发依赖项。 确定在应用程序中是否实际使用了有漏洞的代码。\n* **过去 30 天内关闭的警报，包括固定的 Dependabot警报数、手动消除和自动消除的警报数**：跟踪警报解决进度。 说明如何 GitHub Code Security 帮助你提前检测漏洞。\n* 显示每个存储库的未解决警报总数以及严重性和漏洞利用难易度数据的表\\*\\*\\*\\*：让你可以在存储库级别进行更深入的挖掘。\n\n有关这些指标的详细信息，请参阅 [关于 Dependabot 警报的度量标准](/zh/code-security/concepts/supply-chain-security/about-metrics-for-dependabot-alerts)。\n\n此外，还可以指定复合筛选器，这些筛选器是可用的单个筛选器的组合。 有关筛选器的详细信息，请参阅 [Dependabot 仪表板视图筛选器](/zh/code-security/security-overview/filtering-alerts-in-security-overview#dependabot-dashboard-view-filters)。\n\n## 确定警报优先级的步骤\n\n这些初步步骤可以帮助您识别出最能使组织面临风险的Dependabot alerts，以便告知开发人员要优先处理和修正哪些关键警报。\n\n### 1.定制漏斗顺序以满足组织的需求\n\n可以在“警报优先级排序”图表上自定义默认漏斗顺序，以确保它反映出组织的独特风险特征、业务优先级和合规要求。 请参阅“[查看 Dependabot 警报的指标](/zh/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使用 `relationship:direct` 筛选器筛选警报后，我们可以看到支持的生态系统（如 npm）的直接依赖项上的漏洞。\n\n运行时依赖项由生产中的应用程序使用。 更新此类依赖项可以处理直接影响最终用户或系统的安全漏洞、bug 修复和性能改进。 另一方面，开发依赖项仅在开发、测试或生成过程中使用。 虽然很重要，但这些依赖项中的问题通常不会影响正在运行的应用程序或其用户。\n\n可以使用 `scope:runtime` 或 `scope:development` 筛选器分别显示运行时或开发依赖项的警报。\n\n### 5.考虑警报的存续期\n\n较旧的警报可能表示长期存在的风险。 定期审查和解决陈旧警报，以防止安全债务累积。 例如，在确定特定存储库具有比其他存储库更需要优先处理的警报后，可以：\n\n1. 单击每个存储库表中的存储库名称，以仅显示该存储库的警报。\n2. 使用“排序”\\*\\*\\*\\* 下拉列表中的“较早”筛选器及其他排序条件，按期限微调可视化，显示符合条件的警报。\n\n### 6.利用自动化\n\n使用 Dependabot 的自动拉取请求来快速修复漏洞。 将这些更新集成到 CI/CD 管道中，以加快解决速度和提高效率。\n\n## 最佳做法\n\n* 制定服务级别协议 (SLA)，以基于严重性解决漏洞\\*\\*\\*\\*。\n* 定期监视指标，以确定趋势和重复性问题\\*\\*\\*\\*。\n* 与开发人员协作，确保更新及时并最大程度地减少中断\\*\\*\\*\\*。\n* 记录决策以实现透明操作并为将来的优先级排序提供支持\\*\\*\\*\\*。"}