开源软件构成了现代数字基础设施的基石——从操作系统到云服务，绝大多数软件都直接或间接依赖开源项目。然而，这种广泛依赖也带来了风险：一旦某个被广泛使用的开源仓库遭到篡改，其影响可能波及数百万甚至数十亿用户。
过去几年，针对开源维护者的账户攻击已不再罕见。攻击者通过钓鱼、凭证泄露或供应链渗透，获取仓库推送权限后，悄悄替换合法代码为植入后门的版本。由于下游项目通常自动拉取最新依赖，恶意代码会迅速扩散。
为应对这一威胁，GitHub 正在推广一项关键安全机制：不可变发布（Immutable Releases）。
什么是“不可变发布”？
简单来说，一旦项目维护者将某个版本（如 v1.2.0）标记为“不可变”，该版本的代码、标签和发布资产（如二进制文件）将永久锁定——即使仓库所有者本人也无法修改或删除。
这意味着：
- 恶意行为者即便攻破维护者账户，也无法篡改已发布的版本；
- 用户可以确信，今天下载的 v1.2.0 与一年前发布的完全一致；
- 结合 Git 的 SHA-1 哈希校验，可实现端到端的完整性验证。
为什么这很重要？
传统 Git 仓库允许随时强制推送（git push --force）或删除标签，这在开发阶段很灵活，但也为供应链攻击留下缺口。例如，攻击者可删除旧标签、重新打上相同名称但内容不同的新标签，诱导 CI/CD 系统拉取恶意代码。
而“不可变发布”通过 GitHub 的发布（Releases）系统实现更强约束。启用后，每个发布版本都获得唯一、不可变的 URL 和校验信息，成为可信的分发锚点。
如何启用？
目前，该功能需项目维护者在创建 Release 时手动勾选“Make this release immutable”（使此发布不可变）。GitHub 也在推动将其设为默认选项，尤其对被大量依赖的关键项目。
此外，GitHub 还鼓励项目：
- 使用 verified commits（经 GPG 签名的提交）；
- 启用 two-factor authentication (2FA)；
- 通过 dependabot alerts 监控依赖漏洞。
局限与展望
需要注意的是，“不可变发布”仅保护已发布的版本，不影响主分支的日常开发。它也无法防止攻击者发布一个全新的恶意版本（如 v1.2.1-malicious）。因此，用户仍需结合版本审计、SBOM（软件物料清单）和运行时监控等多层防御。
但毫无疑问，这项机制大幅提高了篡改历史版本的成本，是开源供应链安全的重要一步。
评论