2026/7/21 · #技术 · ~2.5k 字 · 浏览量：... 由于许多生态系统攻击事件，包管理器（以及打包工具和管理者）显然对冷却时间情有独钟（如npm、pnpm、yarn等）。因此，它们的上游注册表的冷却时间被设置为大约7天或24小时。听起来像蜜糖一样甜美。除了这实际上并不起作用。我会说这不是蜜糖，而是一个会陷阱的蜜罐。等待安全，或者等待戈多 一些人正在等待社区在安装包之前对其进行“审查”。然而，人们不知道合适的冷却时间是多少（例如，yarn是7天，pnpm是3天）。另外，剧透一下：人们也不知道谁会进行审查。隐含的假设是，社区中会有人会：提前安装每个包（因为他们是热心人）注意到异常（因为他们聪明）在大众到达之前发出警报（因为他们有最好的网络喇叭）而这一切都是免费的！但现实并没有那么宽容。如果每个人都设定冷却时间，就不会有早期采用者。每个人都在等着其他人成为金丝雀，而金丝雀并不存在。因此，他们正在等待戈多，而……戈多并不会到来。依靠CI/CD，既无用又太晚 一些人使用管道或某些CI/CD（是的，不一定是人为的），通过某个dependabot PR拉取最新包。当存在恶意代码时，会发生两种结果之一（取决于CI是否可被利用/有价值）：恶意代码要么被忽视，要么成功。而PR被合并，开发人员在没有第二个想法的情况下进行npm install。由于没有人和任何东西查看仍然不受信任的代码（读取package-lock.json不算！），人们和机器在安装之前对此问题一无所知，恶意代码仅在影响开始显现时被发现。不用说，那时已经太晚了。因此，我会说DYOR确实重要 总而言之，等待而不采取行动是行不通的。那么该怎么办呢？我建议“自己做研究”：将供应商代码视为从互联网上下载的随机Windows EXE。带上静态分析工具。带上SAST。带上沙箱。带上你的HIPS。对供应商代码进行LLM辅助审计。当然，在dependabot PR合并或开发人员在他们的计算机上安装它们之前。停止冷却或躺平。相反，开始主动扫描，这样它就不再是安全表演中的一场电影。