会被渗透

去年秋天，被渗透我在一个技术论坛上看到有人发帖说，被渗透自己公司内网被一个“看起来人畜无害”的被渗透第三方库偷了数据。那个库在GitHub上有两千多颗星，被渗透代码写得挺规矩，被渗透文档也齐全。被渗透没人想到它会在某个版本里偷偷加了一段混淆过的被渗透代码，专门检测运行环境里有没有特定企业的被渗透内网域名。有的被渗透话，就把环境变量里的被渗透数据库连接串往一个远东的IP地址发。

这事后来被扒出来，被渗透那个库的被渗透维护者账号是买的。前一个维护者不干了，被渗透挂到市场上卖，被渗透新主人改了两次代码，被渗透第三次才动手。中间隔了八个月。

渗透这件事，大多数人脑子里浮现的是黑客敲键盘、屏幕上一堆绿色字符往下滚。现实里最有效的渗透往往跟技术关系不大。你装了一个npm包，它依赖另一个包，另一个包又依赖一个三年前没人维护的包。那个包的作者早就忘了自己写过这东西，邮箱也废弃了。有人给这个废弃邮箱发了封邮件，说“我想帮你接手维护”。三天后，新版本发布了。

供应链攻击这个词听起来很专业，说白了就是：你信任A，A信任B，B信任C，而C已经被人换了芯。你防住了自己家的门，但门锁是别人造的，造锁的人被收买了，你根本不知道。

我认识一个做安全审计的朋友，他跟我说过一个细节。他们团队曾经花了两周时间审查一个开源项目的所有提交记录，最后发现恶意代码藏在一个测试文件里。那个测试文件平时根本不参与构建，但在某个特定条件下会被引用。攻击者赌的就是没人会去看测试文件里的每一行。

更让人不舒服的是，这种渗透不需要多高的技术。它需要的是耐心。攻击者可以等半年、一年，等那个合适的时机。你代码review再仔细，也不可能每次都把依赖树里的每一个节点翻个底朝天。你只能选择信任，而信任本身就是攻击面。

前阵子有个做前端的朋友问我，怎么判断一个开源库安不安全。我说你判断不了。你只能看它的star数、issue活跃度、最近提交时间，但这些全是表面指标。一个被收购的库，star数不会掉，issue照样有人回，代码风格也没变。变的是某一行里多了一个不起眼的字符。

有人提议说那就别用第三方库了，全部自己写。这不现实。现代软件开发的本质就是站在别人的肩膀上，你不可能从零开始造每一个轮子。你能做的只有两件事：一是尽量减少依赖，二是假设你依赖的东西迟早会出问题。

减少依赖的意思是，每次你想引入一个新库之前，先问自己：这个功能我真的需要一整个库吗？能不能用二十行代码解决？很多时候答案是能。第二件事更残酷：你得默认你的构建管道、你的CI/CD、你的包管理器，都可能已经被渗透了。所以敏感数据永远不要放在构建环境能碰到的地方。

那个论坛帖子最后有人回复说：“我们公司现在要求所有第三方库必须锁定版本，而且每次升级都要人工审查diff。”底下有人回：“你审得过来吗？”

审不过来。但至少比不审强。

渗透不会消失。它只会变得更安静、更耐心、更像正常代码。你唯一能做的，就是别把信任当成默认选项。

很赞哦!（1）