源码泄露漏洞

2019年，源码一位安全研究员在GitHub上搜索某款企业级VPN产品的泄露配置文件时，意外翻到了一个标记为“internal-use”的漏洞仓库。里面躺着该产品的源码完整后端源码，包括硬编码的泄露数据库密码和一套未公开的API密钥。这个仓库存在了将近三年，漏洞被fork了四十多次。源码厂商后来发公告说“未发现恶意利用痕迹”——这种话你信吗？泄露反正我不信。

源码泄露这事，漏洞本质上跟把家门钥匙插在锁孔上没区别。源码问题不在于有没有人路过，泄露而在于你根本不知道谁已经配过一把。漏洞

泄露的源码渠道远比想象中多

很多人第一反应是“黑客攻破了服务器”。实际情况恰恰相反，泄露大部分源码泄露根本用不上什么高级攻击手段。漏洞公开的代码托管平台是重灾区。开发者用个人账号建仓库，忘了设为私有，推上去的那一刻就公开了。更隐蔽的是CI/CD流水线——构建日志里打印出环境变量、配置文件路径、甚至完整的源码打包地址，这些日志默认保留90天，权限设置稍微松一点，整个互联网都能翻到。

还有外包。项目赶工期，把模块甩给第三方团队，对方用完代码往自己的GitLab上一扔，权限设成“内部可见”。项目结束后没人清理，过个一年半载，那个GitLab实例因为欠费被回收，数据流落到什么地方就不好说了。我见过一个案例，某金融公司的风控规则引擎源码，最后是在一个俄罗斯的破解论坛上被发现的，距离外包合同结束已经过去两年。

泄露之后发生了什么

拿到源码的人不会立刻动手。先读代码，找逻辑漏洞——那些在黑盒测试中永远碰不到的边界条件。比如某电商平台的优惠券系统，源码里写了一个“如果用户ID取模等于特定值则跳过风控校验”的分支，这显然是开发阶段留的调试后门，上线时忘了删。黑盒测试一万年也测不出这个，但读源码的人五分钟就能定位。

更常见的是供应链攻击。源码里往往包含内部服务的调用凭证、私有npm包的token、甚至生产环境的SSH密钥。攻击者不需要直接攻击目标，通过源码里暴露的跳板机就能横向移动。2021年Codecov事件就是这么玩的——攻击者篡改了他们的bash上传脚本，而那个脚本的源码在GitHub上公开可见，谁都能看出注入点在哪。

为什么总是事后才知道

企业对自己的源码泄露几乎没有任何实时感知能力。代码托管平台不会主动通知你“嘿，你有个仓库公开了”。安全团队做资产梳理时，注意力都在域名、IP、端口上，源码仓库往往不在清单里。等到发现的时候，通常是因为两个原因：要么是攻击者已经利用了漏洞，要么是某个安全研究员在推特上发了截图。

我跟踪过十几个源码泄露案例，从公开到修复的平均时间超过400天。最离谱的一个，某政府承包商把含有选民数据库连接字符串的源码放在了公开的S3桶里，存在了六年。六年，足够一个脚本小子变成资深渗透测试工程师了。

能做什么

别指望开发者永远不犯错。现实的做法是假设源码迟早会泄露，然后围绕这个假设做设计。密钥管理用Vault或者KMS，别写在配置文件里。内部服务的调用加双向TLS认证，光靠一个token就能访问数据库的设计本身就是定时炸弹。CI/CD日志做脱敏，环境变量打印的时候自动打码。

还有一点，监控公开代码平台上的关键词。GitHub的搜索API、GitLab的全局搜索、甚至Pastebin的爬虫，都能用来做早期预警。成本不高，但能把发现时间从400天压缩到几天。

源码泄露不是“会不会发生”的问题，是“什么时候发生”和“发生了你知不知道”的问题。大部分公司连第二个问题都答不上来。