2026 年依赖管理困境：更新还是不更新，这是个危险的问题

原文来源：Mendral Blog — Olivier Gambier 深入剖析了 2026 年软件依赖管理的困境。

从"必须及时更新"到"更新本身成了风险"

如果你在 90 年代末进入 IT 行业，你学到的第一课可能是：仔细审查每项依赖，阅读所有变更日志和补丁说明，及时跟进更新。

这句话在今天听起来，简直像来自另一个时代的遗物。

在 npm + Dependabot + AI 代码头也不回地 Merge 的今天，"审查依赖"早就成了一句空话。Gambier 直言不讳：

"我们从不捐钱给上游开源项目，也从不认真阅读 Dependabot 的 PR diff。别假装你没做过。"

供应链攻击的升级

从 2010 年代中期开始，业界逐渐意识到一个残酷的事实：开源维护者不是免费劳动力，他们同样超负荷工作、人手不足、也会犯任何正常人会犯的错误。 而他们的工作支撑着地球上大部分软件。

随着时间推移，情况不断恶化。

2025-2026 年，供应链攻击已经从"找到某个开源组件里的漏洞"进化到"直接攻入开发者账号，投递武器化版本"。理由很简单——如果整个供应链几乎不验证任何东西，直接植入恶意代码显然比找漏洞效率高得多。

仅仅过去 12 个月，我们就经历了：

• Shai Hulud——npm 生态的重大供应链事件
• Nx singularity——构建工具的后门投递
• axios——核心 HTTP 库的安全事件
• TeamPCP、chalk / debug / qix、tj-actions/changed-files——这个名单还在变长

Dependabot 从帮手变成了问题

Gambier 提出了一个尖锐的观点：

依赖更新是不受信任的代码贡献。

想想看——你项目的 PR 会经过严格审查才能合并。但当 Dependabot 推送一个"更新依赖到最新版本"的 PR 时，大多数人直接点 Merge，甚至不看 diff。

"依赖"和"直接代码贡献"之间的概念差异，只不过是一种建立在"你可以信任邻居家比自己家更安全"这一荒谬假设之上的幻觉。

讽刺的是，Dependabot 这类工具在 5-10 年前确实是重大进步。但现在，它们已经成为过去 12 个月里最热门的供应链攻击分发渠道。

Gambier 直呼："Latest" 必须死。软标签必须死。未固定的版本范围必须死。

AI 代理让一切雪上加霜

文章指出，过去两年——尤其是过去六个月——最大的变量是 AI 编码代理在企业中的广泛采用。

GitHub 已经公布了一些平台数据：AI 生成代码的提交量显著增加。不管你对 AI 编码的效率有什么看法，有一点无可辩驳：最后一道人际关系防线——代码审查——已经被彻底冲垮了。

一些知名公司甚至开始追求完全自动化的 SDLC，让代理合并其他代理的代码，完全没有人工介入。

"坦率地说，还有谁在关注这件事？正常人应该已经在尖叫声中崩溃了。"

出路在哪里？

Gambier 认为，倒退不是出路。回归手动审查、私有分支、三周冷静期——这些只是新时代的系统管理员抱着 Apache 1.3 配置不撒手，最终会被行业对速度的需求碾过。

他给出的方向很明确：

人类已经无法再管理现代软件供应链安全了。 这不是一个开放的问题——我们已经失败了。

• CVE/NVD 体系已名存实亡
• 我们几乎不再审查代码
• 即使能审查，我们也很少自己打补丁
• 有能力的公司选择私有 fork 或内部重写，但这不可持续

他给出了一个尖锐的讽刺：

"也许 OpenSSL 还会出问题，但我们不知道怎么修它，更别说重写了。我们甚至不清楚自己到底用了它的哪些部分。就算知道，我们也没有时间处理它。修复的成本比偶尔应对一次全球性灾难还要高。所以，让我们继续盲目地吸收他们发布的任何东西——至少我们和其他人一样（不）安全。哦对了，我们是 ISO 认证的。"

结语：信任一切，验证……没有验证

Gambier 的文章实际上提出了一个无解的问题：当代码生产速度被 AI 提升了几个数量级，人类审查和供应链验证的能力却原地踏步时，我们该如何自处？

传统的"信任但验证"已经变成"不信任，但也没什么好办法验证"。AI 时代的软件开发安全，可能需要整个行业的基础设施和思维方式进行根本性的重建。

在那之前，每次跑 pnpm add 时手心出汗——可能反而是最合理的反应。