供应链安全藏在没人核查的代码缝隙里

上周去南京软件谷跑客户，在走廊撞见个相熟的技术负责人，蹲在消防通道门口抽烟，烟蒂扔了小半堆。刚被等保整改打回来。原因不是自己写的核心代码有漏洞——是引的第三方报表组件里，藏了个半年前就被公开的后门。他说当时看到整改通知的时候，整个人都麻了。

没人愿意翻的依赖树

现在做项目谁还从零写所有功能？npm拉个工具库，Maven引个日志组件，有时候连前端的日期选择器都是直接下的开源版本。

快。

太省时间了。

很多团队的依赖声明文件里，列的组件版本跨度能拉到三四年前，只要本地跑测试不报错，根本不会去看上游仓库最近半年有没有被人提交过恶意代码，更不会逐行核对组件的哈希值和官方发布的是不是对得上。没人愿意花时间翻完整棵依赖树——你以为自己只引了一个轻量的工具库，顺着依赖链往下挖，可能嵌套着十几个没人维护、早就停止更新的子组件，其中某一个的漏洞，就能把整个系统的门给拆了。

之前碰到个做电商SaaS的小团队，为了省三天开发时间，引了个开源的图片压缩库。上线三个月才发现，这个库在处理大于2M的用户上传图片时，会悄悄把原图的存储地址回传到境外的一台匿名服务器上。

损失算谁的？

开发说我是从公开的官方仓库拉的，没毛病。运维说我只管部署，不管代码逻辑。安全岗的员工说季度扫描漏了这个组件的最新版本，毕竟不在重点监控的组件列表里。

扯皮扯了半个月，最后还是团队自己掏了钱，给所有受影响的用户发了补偿。

被忽略的交付链路

说白了，很多人对供应链安全的理解还停留在“扫开源组件的已知漏洞”这一步。

根本不是。

你自己的代码从写出来，到最终打包成安装包送到用户手里，中间经过的所有节点，全是供应链的一部分。代码仓库的权限是不是太松？CI/CD的构建脚本是不是谁都能改？交付用的对象存储桶，是不是设置了公开可读？

这些环节出的问题，比开源组件的公开漏洞隐蔽得多。

有个团队之前为了图方便，把CI流水线的触发权限开放给了所有外部协作者。结果有个离职的合作方员工，在权限还没被完全回收的间隙，往构建脚本里加了一行代码，把最终产出的Windows安装包替换成了带挖矿程序的版本。等用户反馈自己电脑风扇转得像要起飞的时候，已经有不少装了这套软件的终端被偷偷跑起了算力任务。

商业扫描工具能帮你找到公开的CVE漏洞，能帮你识别依赖组件的已知风险，但它扫不到你内部交付链路里的权限漏洞，扫不到有人故意在构建环节塞进去的私货。很多团队花大价钱买了顶级的安全扫描设备，结果连“谁能改生产分支代码”这种最基础的问题都答不上来，钱全打了水漂。

算得过来的安全成本

很多老板一听要做供应链安全，第一反应是又要加预算，又要招一堆专职安全人员，太费钱。

真不是。

南京软件谷这边的中小团队，前几年总觉得黑客不会盯上自己这点业务，直到去年有几个团队因为开源组件藏的漏洞，被勒索软件加密了整个代码仓库，连备份服务器都被顺带掏了，才开始正经坐下来梳理自己的供应链链路。算下来，真正花的钱比当时给勒索者付的赎金零头还少。

其实要做的事一点都不复杂。先把所有依赖组件的版本全部锁死，不要用那种写着latest的模糊版本号。每周自动跑一次组件哈希值校验，跟上游官方的发布值对一遍。把代码仓库的权限按最小权限原则收一遍，离职人员的权限当天就回收，CI/CD流水线的改动加个双人审批。把那些三年没更新、没人维护的废弃组件，全部替换掉。

这些事不费钱。

真的。

很多团队之前出问题，根本不是因为没有顶级的安全设备，而是连最基础的权限台账都理不清。谁有生产环境的访问权，谁能改构建脚本，谁能直接碰用户的数据库，翻出来的名单能吓自己一跳——有三个已经离职半年的销售，居然还有生产环境的只读权限。

上次在走廊碰到的那个技术负责人，整改到最后也没花多少预算。就是把所有第三方组件的版本全部锁死，把CI流水线的权限收回到两个核心开发手里，再配了个基础的开源组件扫描工具，把依赖树里那些早就停止维护的组件全部替换掉。前后花了不到两周。

他说之前总觉得供应链安全是个特别玄的事，要搞一堆复杂的设备，请一堆外部专家，真上手做了才发现，大部分漏洞都藏在偷懒的细节里。

哪有那么多玄乎的攻击。

都是人懒出来的窟窿。