Skip to main content

关于你代码及依赖项中的漏洞暴露情况

了解你自己的代码和第三方依赖项中的漏洞如何对组织的整体安全风险以及如何衡量和降低风险造成影响。

谁可以使用此功能?

需要 GitHub Team 或 GitHub Enterprise

未修复漏洞的风险

你的组织在编写和维护的代码以及代码使用的open source或第三方依赖项中都暴露了漏洞。 如果要阻止,评估暴露的漏洞至关重要:

  •         **非计划停机及运营中断**。 利用漏洞可能会导致应用程序中断、服务质量下降或关键系统中的级联故障,从而中断业务运营。
    
  •         **增加的修复成本**。 越长易受攻击的代码仍无法解决,解决难度和开销就越高,尤其是在代码深度集成或事件发生时。 及早检测和修复可降低昂贵的事件响应、紧急补丁和声誉损害的风险。
    
  •         **风险的广泛传播**。 易受攻击的模块和依赖项通常跨多个应用程序和服务重复使用,这意味着单个缺陷可以在整个组织中传播,从而加剧开发的风险和影响。
    
  •         **供应链被攻破**。 攻击者可以利用open source或第三方依赖项中的漏洞来注入恶意代码、提升特权或获得对系统未经授权的访问。 被攻破的依赖项可能成为恶意行为者的间接入口,导致大范围安全事件。
    
  •         **合规性及许可问题**。 许多法规和行业标准要求组织主动解决其软件供应链中已知的漏洞。 未能修正易受攻击的依赖项可能会导致不合规、审核、法律处罚或违反open source许可证义务。
    

定期评估漏洞暴露有助于尽早识别风险并确定修正的优先级。

监视存储库中易受攻击的代码的方法

  •         **Code scanning** 会自动监控你项目的代码漏洞。 当它在拉取请求中检测到安全问题时,它会创建一个警报,并提供用于解决漏洞的自动修复建议。 这会降低解决障碍,并帮助确保项目保持安全。 请参阅“[AUTOTITLE](/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning)”。
    
  •         **Dependabot** 自动监控您的项目依赖项,检查潜在的漏洞和过时的依赖包。 当检测到安全问题或新版本时,它会创建拉取请求以更新受影响的依赖项,帮助你快速应对安全风险并保持软件更新。 这减少了手动操作,并有助于确保你的项目保持安全。 请参阅“[AUTOTITLE](/code-security/getting-started/dependabot-quickstart-guide)”。
    

GitHub 提供全面的 Dependabot 指标,帮助你在组织内所有仓库中监控、优先排序并修复这些风险。 请参阅“关于 Dependabot 警报的度量标准”。

减少组织漏洞暴露

减少组织漏洞暴露需要持续了解跨存储库的风险、修正进度和策略强制实施。 Dependabot 和 code scanning 指标提供此可见性。 使用以下最佳做法来监视和减少组织的漏洞泄露:

监视依赖项的漏洞指标

使用 Dependabot 的指标概览了解组织当前依赖漏洞状态。 请参阅“查看 Dependabot 警报的指标”。

  •         **警报优先级排序:** 查看未解决的 Dependabot alerts 数量,并使用 CVSS 严重性、EPSS 利用可能性、可用补丁以及受影响依赖项是否实际在已部署产物中使用等过滤器。 请参阅 [Dependabot 仪表板视图筛选器](/code-security/security-overview/filtering-alerts-in-security-overview#dependabot-dashboard-view-filters)。
    
  •         **仓库级别分析:** 识别哪些仓库具有最多的关键或可利用漏洞。
    
  •         **修复跟踪:** 跟踪已修复警报的数量和比例,以评估漏洞管理计划的有效性。
    

监控新 code scanning 警报的引入

使用 code scanning 的警报视图,了解组织拉取请求中的修复活动。 请参阅“查看拉取请求警报的指标”。

  •         **拉取请求中的警报:** 查看有多少个警报被检测到并在未得到解决的情况下合并到默认分支中。
    
  •         **最常见的规则:** 确定需要开发人员教育时经常触发的规则。
    
  •         **存储库级别的细分:** 确定哪些存储库在拉取请求中检测到最多的警报后,仍被合并到默认分支中。
    
  •         **修复跟踪:** 跟踪已修复警报的数量和比例,以评估漏洞管理计划的有效性。
    

确定修正工作的优先级

重点关注对组织风险最高的漏洞。

  • 优先考虑高严重性或关键严重性的警报。 对于 Dependabot alerts,还应优先考虑高 EPSS 分数和可用补丁。
  • 使用存储库细分信息将修正工作定向到风险最大的项目。
  • 鼓励开发团队通过存储库自定义属性和利用生产环境,解决在已部署的工件中实际存在的漏洞。 参见 使用生产上下文确定 Dependabot 和代码扫描警报的优先级
  • 创建安全活动,以鼓励并跟踪高优先级 code scanning 警报的修复。 请参阅“创建和管理安全活动”。

传达风险和进度

  • 使用指标页向利益干系人传达关键风险因素和修正进度。
  • 定期更新趋势,例如未解决关键漏洞的减少或修复率的提升。
  • 突出显示需要额外支持或关注的仓库或团队。

建立并强制实施策略

  • 设置组织范围的安全配置,在所有现有和新仓库上启用 Dependabot 和 code scanning。 请参阅“关于批量启用安全功能”。
  • 启用依赖项评审以便在所有存储库中对拉取请求进行评论。
  • 创建组织范围规则集,以保护默认分支,并要求在合并拉取请求前修复关键 code scanning 警报。 请参阅“管理您组织存储库的规则集”。
  • 与仓库管理员协作,在可能情况下启用自动安全更新。 请参阅“关于 Dependabot 安全更新”。

评估警报的影响

  • 定期审查 Dependabot 和 code scanning 警报如何帮助阻止安全漏洞进入代码库。
  • 利用历史数据展示主动依赖管理的价值。