八年前，开发者担心的是框架本身有没有漏洞。现在，真正危险的是安装包的那一刻。
最近TanStack的供应链攻击事件，把这个问题彻底摆上了台面。攻击者没有碰你的运行时代码，而是直接污染了软件交付管道——你信任的包管理器、发布流程、CI配置，全成了靶子。
攻击时间线很短：恶意版本发布，短时间内被大量下载，然后被发现、清理。但就在这"短时间"里，无数项目的依赖树已经被种下雷。TanStack团队的复盘帖子里有个细节值得注意——他们花了相当篇幅讲"怎么发现的"，而不是"漏洞长什么样"。这说明现代供应链攻击的隐蔽性：它不像传统漏洞那样等你调用，而是潜伏在构建环节，随打包流程自动执行。
这次事件后，有四条措施正在从"建议"变成"刚需"：
第一，设置最小发布延迟。新包上线后强制等待24-72小时再安装，给社区留出发现恶意代码的窗口。代价是紧急安全补丁也会慢半拍，但这是权衡。
第二，收紧CI和发布权限。太多项目的自动化流程拥有过度授权，攻击者一旦突破一个环节，就能一路直达生产环境。
第三，锁定精确版本号。不要用"^1.0.0"这种宽松范围，直接写死"1.0.3"。代价是升级变繁琐，但你确切知道自己跑的是什么代码。
第四，启用发布来源验证。npm等 registry 的 provenance 功能可以追溯包是谁、在哪台机器上构建的，伪造成本大幅提高。
这些措施都有摩擦成本。精确版本意味着手动处理更多补丁，发布延迟可能卡住紧急修复。但供应链攻击的本质就是"速度战"——攻击者赌的是你自动拉取最新版的惯性。打破这个惯性，就是打破攻击者的窗口期。
一个趋势已经很明显：应用安全的边界正在外移。CI管道、包注册中心、发布权限、依赖信任，这些曾经被视为"基础设施"的东西，现在必须被当作应用本身的一部分来防护。你的代码可能写得滴水不漏，但安装依赖的那一刻，防线就已经被突破了。
热门跟贴