Skip to main content

使用指标确定 Dependabot 警报的优先级

可以通过分析提供的指标来确定组织中 Dependabot alerts 的优先级。 使用此方法,可以告知开发人员首先关注最重要的漏洞。

谁可以使用此功能?

具有管理员角色的组织所有者、安全管理员和组织成员

使用指标确定 Dependabot alerts 的优先级

应用程序安全 (AppSec) 经理经常面临大量的 Dependabot alerts,因此确定要首先解决的漏洞很有挑战性。 Dependabot 指标提供了有价值的见解,有助于有效地确定警报的优先级,确保及时解决关键安全问题。 用户可以做出明智的决策,集中资源解决影响最大的漏洞。 此方法增强了组织的安全态势,并简化了漏洞管理。

了解 Dependabot 指标

Dependabot 指标提供有关依赖项中检测到的漏洞的详细信息。 关键指标包括:

  • 严重性****:指示漏洞的潜在影响(例如,低、中、高、严重)。
  • 可利用性****:评估某个漏洞可被利用的可能性。
  • 依赖关系****:区分直接依赖项和传递性依赖项。
  • 依赖项范围****:区分运行时依赖性和开发依赖项。 确定在应用程序中是否实际使用了有漏洞的代码。
  • 过去 30 天内解决的警报数(包括 Dependabot 修复、手动消除和自动消除的警报数)****:跟踪警报的解决进度。 说明 GitHub Code Security 如何帮助你提前检测漏洞。
  • 显示每个存储库的未解决警报总数以及严重性和漏洞利用难易度数据的表****:让你可以在存储库级别进行更深入的挖掘。

此外,还可以指定复合筛选器,这些筛选器是可用的单个筛选器的组合。 有关筛选器的详细信息,请参阅 Dependabot 仪表板视图筛选器

确定警报优先级的步骤

以下首要步骤可帮助你确定为组织带来最大风险的 Dependabot alerts,以便你可以告知开发人员要侧重修正哪些警报。

1.定制漏斗顺序以满足组织的需求

可以在“警报优先级排序”图上自定义默认漏斗顺序,以确保它反映组织的独特风险配置文件、业务优先级和合规性要求。 请参阅“查看 Dependabot 警报的指标”。

2.侧重处理关键和高严重性的警报

首先,使用 severity-criticalseverity-high 筛选器确定严重性最高的警报。 这些漏洞会造成最大的风险,通常按合规性标准优先处理。 然后,可以

3.评估可利用性和可访问性

确定最有可能在代码库中利用的漏洞的优先级。 若要识别漏洞利用可能性最高的警报,可以使用与某个值关联的 epss_percentage 筛选器(例如 epss_percentage>=0.10)。

4.查看依赖项范围和关系

直接依赖项通常更易于更新,可能对应用程序的安全性产生更大的影响。 建议尽可能先解决这些问题,再解决传递性依赖项。 使用 relationship:direct 筛选器筛选警报后,我们可以看到支持的生态系统(如 npm)的直接依赖项上的漏洞。

运行时依赖项由生产中的应用程序使用。 更新此类依赖项可以处理直接影响最终用户或系统的安全漏洞、bug 修复和性能改进。 另一方面,开发依赖项仅在开发、测试或生成过程中使用。 虽然很重要,但这些依赖项中的问题通常不会影响正在运行的应用程序或其用户。

可以使用 scope:runtimescope:development 筛选器分别显示运行时或开发依赖项的警报。

5.考虑警报的存续期

较旧的警报可能表示长期存在的风险。 定期审查和解决陈旧警报,以防止安全债务累积。 例如,在确定特定存储库具有比其他存储库更需要优先处理的警报后,可以:

  1. 单击每个存储库表中的存储库名称,以仅显示该存储库的警报。
  2. 使用“Sort”下拉列表中的“Older”筛选器以及其他排序条件来微调警报的可视化效果,以符合按存续期排序的条件****。

6.利用自动化

使用 Dependabot 的自动拉取请求快速修正漏洞。 将这些更新集成到 CI/CD 管道中,以加快解决速度和提高效率。

最佳做法

  • 制定服务级别协议 (SLA),以基于严重性解决漏洞****。
  • 定期监视指标,以确定趋势和重复性问题****。
  • 与开发人员协作,确保更新及时并最大程度地减少中断****。
  • 记录决策以实现透明操作并为将来的优先级排序提供支持****。