为何在版本控制中需采用代码签名？

一、攻击者可篡改代码的关键环节 #

• 本地推送前：若攻击者拿到开发者本地机器权限（比如通过恶意软件、物理入侵），能直接修改本地仓库文件，甚至替换已提交但未推送的提交记录，让开发者误把恶意代码推送到远程仓库。
• 远程服务器端：攻击者一旦攻陷Bitbucket/Git服务器的文件系统或拿到管理员权限，可直接修改服务器上的仓库文件、提交记录，甚至替换整个分支的内容。
• 代码拉取/分发过程：开发者从远程拉取代码时，攻击者可通过中间人攻击篡改传输中的代码；或者在开发者本地环境被控制时，替换拉取到本地的代码文件。
• 构建发布阶段：如果攻击者控制了CI/CD构建服务器，能在编译、打包过程中植入恶意代码，生成带毒的发布包。

二、Bitbucket/Git仓库的安全局限性 #

Git自带的哈希校验能保证仓库内提交记录的哈希一致性，但存在明显短板：

• 本地仓库被篡改后，恶意提交只要哈希合法，就能被推送到远程仓库，Git不会验证提交者身份或内容是否被篡改。
• 若远程服务器本身被攻陷，攻击者篡改服务器上的仓库数据后，其他开发者拉取的就是篡改后的内容，此时Git的哈希校验无法识别，因为整个仓库的哈希链已被恶意重构。

三、代码签名的核心适用场景 #

• 本地提交校验：对本地的提交（commit）或标签（tag）签名，确保推送到远程的代码确实是开发者本人的合法提交，避免本地被篡改后推送恶意内容。
• 远程仓库准入与校验：配置远程仓库强制要求所有提交必须签名，拦截未签名的恶意提交；开发者拉取代码时，验证远程提交的签名，确保服务器端的代码未被篡改。
• 发布包完整性验证：对编译后的二进制文件、容器镜像等发布产物签名，用户或部署系统拉取后验证签名，确保发布包在分发过程中未被篡改。
• CI/CD流水线防护：在流水线中加入签名校验步骤，确保拉取的源码、构建的产物都是经过认证的，防止流水线被篡改后植入恶意代码。

内容的提问来源于stack exchange，提问作者Yash