git 代码托管理漏洞

上个月，码托某大厂内部仓库的管理代码被完整克隆到了公网。不是漏洞黑客暴力破解，不是码托内鬼下载，只是管理某个开发者在自己的`~/.ssh/id_rsa`私钥文件里，顺手写了一句注释——然后把这个文件传到了GitHub上的漏洞公开仓库。Git的码托分布式特性让这次事故变得极其致命：每个克隆者的本地都保留着完整历史，即使你删掉远程仓库，管理代码已经在几百台陌生电脑里安了家。漏洞

Git的码托漏洞从来不是缓冲区溢出那种东西，而是管理逻辑和信任的漏洞。它的漏洞核心设计——本地仓库包含全量历史——意味着权限控制根本没想象中那么强。你以为删了分支就没事了？码托`git reflog`、`git fsck --lost-found`，管理任何克隆过你仓库的漏洞人都能把“已删除”的提交捞回来。去年有个开发者把AWS密钥提交到公共仓库，五分钟后删除并force push，结果密钥在几小时内就被爬虫扫走，账单多了八千美元。删除不是撤销，是广播。

更隐蔽的问题是子模块和钩子。子模块指向的URL如果被篡改，或者那个URL指向的仓库被攻击者接管，你的代码在`git submodule update`时就会悄悄被替换成恶意版本。钩子脚本更直接——`.git/hooks`里的文件跟随仓库传递？不，Git默认不传递钩子，但很多开发者为了“方便”，把钩子脚本放到仓库里并配置`core.hooksPath`指向它。一旦那个文件被篡改，你每次commit都在执行别人的代码。这种信任链的断裂，比任何0day都难防。

还有个反直觉的事实：Git的SHA-1碰撞攻击在2017年就已经被实际验证。虽然构造两个内容相同、哈希不同的文件仍需要极大算力，但攻击者不需要碰撞整个仓库——他们只需要碰撞一个文件的内容，比如某个依赖包里的压缩文件。一旦碰撞成功，你检查的代码和实际运行的代码就是两码事。业界还在用SHA-1，因为迁移到SHA-256牵扯到所有历史哈希的重算，工作量巨大。这就像住在一栋地基开裂的楼里，大家都清楚危险，但没人愿意搬出去重新装修。

我自己也踩过坑。有次写了个脚本，把`.env`文件加进`.gitignore`，但忘了之前已经track过它。结果每次修改配置，Git都默默记录着变化，直到某天我把仓库推送到GitLab的公开项目——环境变量里的数据库密码瞬间暴露。事后检查，那个文件在历史里躺了三个月，期间至少有两次pull request来自陌生账号。他们没动代码，只是静静地复制了你的凭证。

别指望平台的安全扫描能救你。GitHub的secret scanning能识别常见格式的密钥，但你自己拼接的token、内网域名加密码的组合，它根本看不出来。更别提自建的GitLab或Gitea，扫描能力约等于零。真正管用的只有一条：把仓库当作会泄漏的容器来设计。敏感信息永远不要进版本控制，用环境变量注入，用vault管理，用git-secrets这类工具在commit前拦截。历史记录要定期清理——不是删分支，而是用`git filter-repo`重写历史，然后强制所有协作者重新克隆。

Git给开发者的自由是双刃剑。它让你随时回溯任何改动，也让任何改动都无法真正消失。你在本地敲下的每个commit，都像在公共广场上按下广播键。那些以为“私有仓库”就安全的人，大概率没看过Git的底层存储格式——对象文件就是纯文本，任何有仓库访问权限的人都能直接读取所有内容，包括你以为是加密的、实际只是base64编码的密码。分布式版本控制的本质，是代码的永生。你唯一能做的，就是别把不该永生的东西放进去。