·6 分钟供应链攻击SCA开源
开源供应链攻击，我们团队也不是例外
只要一个npm/PyPI包遭到感染，使用它的所有项目就会跟着遭殃。供应链攻击实际上是如何发生的，以及3层防御。
"我又没写这段代码，为什么我的服务被攻破了？"——这是供应链攻击的典型疑问。问题不在你自己写的代码，而在你安装的别人的代码。
什么是供应链攻击
我们的项目通常依赖数十到数百个开源包（npm、PyPI、RubyGems等）。攻击者只要感染其中一个包，所有安装它的项目就会自动被感染。这比直接攻击你的代码高效得多，因此这种手法近几年大幅增加。
实际上是这样发生的
- 抢注式仿冒（typosquatting）：上传与热门包名称相似的假包（例如
lodash→iodash），等人不小心装错 - 维护者账号被劫持：攻击者劫持一个老旧包的管理员账号，在原本正常的包中偷偷加入恶意代码并发布新版本
- 依赖混淆（dependency confusion）：把和公司内部包同名的包上传到公共仓库，诱使构建系统拉取公共（恶意）版本而非内部版本
以上三种情况，都只需要开发者像平常一样运行`npm install`就会中招。并不是做了什么可疑的操作。
为什么小团队更脆弱
大公司通常会有内部仓库镜像、包审批流程。相对地，独立开发者或小型团队通常装完依赖后就再也不会回头检查。 再加上AI代码生成工具，只要有需要的功能，往往不怎么验证就会建议安装新包，让暴露面更大。
3层防御
- 提交lockfile并以固定版本安装 — 没有
package-lock.json/pnpm-lock.yaml的话，同一份代码每次可能会安装到不同版本。 - 自动扫描依赖漏洞 — 定期，理想情况下每次部署，都确认是否使用了存在已知漏洞（CVE）的版本。
- 升级版本时先浏览一遍变更内容 — 尤其是最近换过维护者、或下载量相对历史很短的包，更新前先看一眼diff，能防止大事故。
供应链攻击不是因为"我做错了什么"而发生，而是信任的别人的代码反过来背叛你的事故。所以防御的对象也不该只是"我的代码"，而应该是"我所使用的所有他人代码"。
WhiteHat Code会扫描仓库的依赖，找出存在已知漏洞的包，并告诉你升级路径。自动扫描是免费的。