"Verified" 提交的缺陷:为什么 GitHub/GitLab 在供应链安全方面做得不够"}],

软件供应链攻击已成为一个重大关注点,凸显了在开发每个阶段采取稳健安全措施的关键需求。确保代码完整性的一个基本方面是提交签名(commit signing),其目的是验证更改的作者身份和真实性。然而,在 GitHub 和 GitLab 等主要 Git 平台如何实现和强制执行提交签名方面存在一个关键差距,使得组织容易受到能够绕过现有 "Verified" 徽标的复杂攻击。

这个问题源于平台无法强制执行特定的签名密钥,允许攻击者以合法、已验证提交的伪装,将恶意代码注入到仓库中。本文探讨了当前提交签名保护措施的局限性、流行平台缺失的功能,以及为弥补这些安全缺陷而给开发团队带来的沉重负担。

"Verified" 提交的幻象

GitHub 和 GitLab 提供 "Require signed commits" 功能,表面上看,通过确保所有推送到仓库的提交都由与提交者账号关联的密钥签名,从而增强了安全性。然而,这种保护从根本上说是存在缺陷的。如果攻击者入侵了开发者的笔记本电脑或其 GitHub/GitLab 账号,他们只需简单地向该账号添加一个新的签名密钥即可。通过这个新的、未经授权的密钥,攻击者随后可以推送恶意提交,而这些提交仍会获得梦寐以求的 "Verified" 徽标。

这种情况创造了一个显著的盲点:作为信任标志的 "Verified" 徽标,反而成为了供应链攻击的一个潜在向量。仅依赖此功能的组织会产生一种虚假的安全感,因为恶意代码可以无缝地集成到其代码库中,且看起来非常合法。

平台功能的关键差距

核心问题在于 GitHub 和 GitLab 缺乏细粒度的控制和强制执行机制。具体而言,这些平台目前不提供:

  • 组织层级的已批准签名密钥白名单: 组织没有内置方式来指定并强制执行一份允许用于签名提交的已批准签名密钥列表(例如,由组织颁发的硬件支持的 YubiKeys)。
  • 基于签名密钥本身的推送拒绝机制: 平台无法配置为在提交由不在已批准白名单上的密钥签名时自动拒绝推送,即使该密钥与一个合法的用户账号关联。
  • 内置的、细粒度的密钥访问审计: 组织只能通过自行流式传输和解析审计日志来了解谁访问了什么,这使得高效检测未经授权的密钥添加或使用变得非常困难。

这些缺失的功能意味着,即使启用了 "Require signed commits",Git 历史记录的完整性仍然容易受到单个被入侵的开发者账号的影响。

当前权宜之计的局限性

面对这些平台功能的局限性,许多组织采取了权宜之计,例如:

  • 在持续集成 (CI) 流水线中重新验证签名: 这涉及在 CI 中添加一个步骤,根据内部白名单重新检查提交签名。
  • 基于未批准密钥的部署拦截: 如果 CI 检测到由未经授权的密钥签名的提交,则停止部署。
  • 使用带有 pre-receive hooks 的自托管 Git: 在自托管 Git 实例上实现自定义 hooks,以便在提交进入仓库之前强制执行签名密钥策略。

虽然这些权宜之计提供了一定程度的检测或预防,但它们都有一个共同的关键缺陷:恶意提交仍然进入了仓库。CI 在事后检测到它,这意味着被入侵的代码已经集成到了代码库中,即使它被阻止了部署。这种“事后”检测对于真正的供应链安全而言是不够的,因为真正的目标是防止恶意代码进入受信任的仓库历史记录。

组织承担的负担

这些基础安全功能的缺失,迫使组织(尤其是较小的开发团队)不得不投入大量资源进行高强度的努力,以确保其软件供应链的安全。这包括:

  • 向每个开发者颁发硬件安全密钥 (例如,YubiKeys): 一项重大的物流和财务投入。

  • 建设自定义的验证和审计流水线: 开发定制化系统来强制执行密钥策略并监控活动。

  • 将审计日志流式传输到安全信息和事件管理 (SIEM) 系统: 需要额外的基础设施和专业知识来进行日志分析和告警。

  • 升级到企业级版本以获得基础可见性: 通常会为那些本应是标准安全功能的特性而支付更高的费用。

对于这些被视为“入门级”的安全需求,投入如此高水平的努力,是导致显著挫败感的一个来源,这些资源本应可以用于核心开发和创新。

对更好平台支持的呼吁

现状凸显了现代开发的安全需求与领先 Git 平台提供的功能之间的严重脱节。虽然 GitHub 等平台在 AI 驱动的编程助手等功能上投入了大量资金,却未解决防止 "Verified" 供应链攻击的基础性安全机制。组织需要平台提供强大的、内置的能力来:

  • 强制执行特定的、经组织批准的密钥进行签名。 n 在入口处拒绝不符合这些密钥要求的推送。
  • 提供透明且可操作的密钥管理和使用审计追踪。

如果没有这些能力,单个被入侵的开发者账号导致 "Verified" 供应链攻击的威胁,对于全球开发团队而言,仍然是一个切实且紧迫的 concern 关注点。确保 Git 日志和历史记录的完整性,应该是平台提供商的首有的优先级任务。

Sources