上周在南京软博会蹲了三天，跟几个做DevSecOps的工程师挤在会场外的连锁便利店啃菜包，聊到最后几个人都沉默了。他们公司上个月刚上线的大促活动系统，半夜被安全扫描扫出个高危漏洞，溯源追了三层依赖，最后发现是个没人维护的图片处理小工具，有人在里面塞了挖矿程序，已经悄摸跑了快两周。
没人在意的三层依赖
麻烦就在这。
你写代码的时候，只会引入自己挑的那个包。比如你要做个文件上传功能，会引个广受好评的uploader，这个uploader内部又依赖了一个做格式校验的小工具，这个小工具又引了一个处理图片压缩的脚本。三层往下，没人会去翻最后那个脚本的源码。
说实话，大部分团队的依赖扫描工具，默认只会扫第一层直接依赖。第二层第三层的，要么没开全量扫描，要么扫出来一堆低危漏洞，直接一键忽略了。
很多人对供应链安全的认知，还停留在“硬件被换了芯片”“供应商泄露数据”的层面，根本没意识到，自己每天敲的代码，从第三行开始就已经不在自己的掌控里了。之前跟某大厂的安全负责人聊，他说他们去年一年处理的供应链安全事件里，80%以上都是这种嵌套依赖出的问题。最夸张的一次，是个做前端可视化的组件，内部依赖了一个已经废弃了两年的日期处理库，有人把这个废弃库的维护权抢过来，塞了窃取用户cookie的代码，传了不到72小时，全球已经有三万多个项目间接引了这个包。
你说这算谁的错？组件作者没做错，他引的时候这个库还是干净的。用组件的团队更没做错，他们连这个库存在都不知道。
扫描工具的取舍陷阱
很多人会说，那全量开扫描不就完了？
哪有那么简单。
全量扫描开了之后，你每次提交代码，CI流程要多跑至少15分钟。大一点的项目，依赖包有上千个，扫一次要半小时。开发嫌慢，运维嫌占资源，最后大家商量一下，把扫描阈值从“所有漏洞”改成“高危以上”，再把每周一次的全量扫描改成每月一次，甚至干脆关了告警。
上个月碰到的那个创业团队，就是因为开了全量扫描之后，每次发版要多等40分钟，开发 leader 直接把安全扫描插件从流水线里踢了。三个月后出事，才发现那个挖矿程序刚引进来的时候，扫描工具其实是报了警的，只是告警被埋在几百条低危通知里，没人看。
还有个更麻烦的事。现在很多团队为了赶进度，会直接从公共代码仓库里拷一段别人写的脚本，连依赖都不看，直接粘到自己的工具链里。比如你要做个自动发版的脚本，搜个现成的，拷过来就能用，谁会去翻这段脚本里藏了多少没写在说明里的依赖？
没人愿意为上游的错买单
这事没那么玄。
供应链安全的核心矛盾，从来不是技术问题。是责任问题。
开源社区的维护者，大部分都是用爱发电，自己抽时间写代码，没义务给你做全量的安全审计。用代码的团队，觉得自己是免费拿的代码，出了问题也找不到人追责，干脆装看不见。之前有个做日志处理的小工具，维护者去年家里有事，半年没更新，有人发现这个工具存在路径遍历漏洞，提了PR没人合，最后只能自己fork一个版本，改完之后发到公共仓库里。结果大部分团队根本不知道有这个fork版本，还是在用原来的有漏洞的版本，直到出事才反应过来。
上次在南京跟几个开发者聊，有人说，他现在做项目，只要是超过三层的间接依赖，要么自己把依赖的源码扒下来，重新编译打包到自己的私有仓库里，要么干脆找个功能差不多的、自己能完全掌控的工具替代。
麻烦吗？麻烦。
但是比被人塞了挖矿程序、跑了半个月才发现，最后交了几万块的算力损失，要划算多了。
上周回上海，地铁上刷到个新闻，说有个开源的登录组件被人塞了窃取支付信息的代码，已经被下载了几十万次。
我翻了翻自己去年写的几个小工具，里面刚好引了这个组件。
赶紧去改了。