Dependabot，GitHub 亲生的自动化依赖管理工具，多少团队的安全防线。
它勤勤恳恳地提 PR、发警报，恨不得把你项目里的每个依赖都更新到最新版。
把它关了？这不就是自废武功吗？
但 Filippo Valsorda，这位前 Go 语言安全团队负责人，最近直接写了一篇檄文，标题简单粗暴：
《Turn Dependabot off》（关掉 Dependabot）。
他的理由很硬：Dependabot 正在让你变得不安全。 它制造了大量的噪音，让你产生了"我在干活"的错觉，实际上却掩盖了真正的问题。
这事儿有点意思，咱们来掰扯掰扯。
一个没人用的函数，引发了全网报警
事情得从一个具体的惨案说起。
前两天，Filippo 发布了一个安全补丁，修复了 filippo.io/edwards25519 这个库的一个漏洞。具体来说，是 (*Point).MultiScalarMult 这个方法有问题。
这个库什么地位？它是 Go 生态的基石之一，光是通过 github.com/go-sql-driver/mysql 这一条线，就在 GitHub 上有 22.8 万个 依赖项目。
听起来很吓人对吧？22 万个项目可能受影响，这绝对是史诗级灾难。
但问题来了：压根就没人用那个出问题的方法。
Filippo 专门查了一下，几乎没人调用 MultiScalarMult。这次的补丁，也就是 v1.1.0 到 v1.1.1 的区别，仅仅只有一行代码——改了一个没人用的方法。
然而，Dependabot 的反应是什么？
它炸了。
就在第二天，Dependabot 向数千个根本不受影响的仓库疯狂发送 PR 和安全警报。
警报里甚至附带了一个看起来很专业、实际上完全是瞎编的 CVSS v4 评分，还有一个让人心惊肉跳的"73% 兼容性评分"，暗示这次更新会导致大量生态崩溃。
更离谱的是，Filippo 收到一个来自 Wycheproof 项目的警报。
这个项目压根就没有导入那个出问题的包，它只导入了一个完全无关的子包 field。
Dependabot 根本不管你有没有用那个有毒的函数，它只看到版本号旧了，就开始疯狂敲锣打鼓。
这不叫安全，这叫骚扰。
狼来了的故事
你可能觉得，误报就误报呗，多点警报总比漏掉好。
大错特错。
Filippo 在文章里一针见血地指出：虚假警报不仅浪费时间，更是在通过"警报疲劳"降低你的安全性。
想象一下，你的邮箱每天都塞满了 Dependabot 的警报。今天是一个没人用的库，明天是一个无关紧要的补丁。你从一开始的紧张兮兮，变成了后来的麻木不仁，最后甚至设置了邮件过滤规则直接归档。
这时候，真正的漏洞来了。
当你真的需要去评估一个严重漏洞、去轮换密钥、去通知用户的时候，你只会习惯性地点击"合并"，把这当成一次普通的依赖升级。
这就是 Dependabot 的逻辑死结：它把所有版本差异都当成安全事件处理。
它无法区分"我引用了这个库"和"我调用了这个漏洞函数"之间的区别。
这种无脑操作，本质上是在把开源维护者和开发者当成机器人。
维护者经常收到莫名其妙的 Issue 和 PR，要求他们升级依赖，仅仅因为某个扫描器报了个警，而那个漏洞根本没被触发。
这不仅是 Toil（无效劳动），更是在透支开源社区的耐心。
别做版本号的奴隶，要做代码的主人
那怎么办？难道我们就裸奔，不更新依赖了吗？
Filippo 给出的方案很硬核，也很符合 Go 语言的哲学：用工具说话，拒绝噪音。
他建议直接关掉 Dependabot，换成两个 GitHub Actions：
- 跑 **govulncheck：这是 Go 官方的漏洞检查工具。它不是简单地比对版本号，而是做静态分析**。它会检查你的代码调用链，看你是否真的"触及"了那个漏洞符号。如果你没调用，它就闭嘴。
- 跑最新版测试：每天定时跑一次 CI，用 go get -u 把依赖升到最新版，跑一遍测试。如果没挂，说明兼容性没问题；如果挂了，你再决定修不修。
看看 govulncheck 的输出，简直是教科书级的"懂事"：
$ govulncheck ./...
=== Symbol Results ===
No vulnerabilities found.
Your code is affected by 0 vulnerabilities.
This scan also found 1 vulnerability in packages you import and 2
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
看到了吗？"虽然你依赖的包里有漏洞，但你的代码没调用它，所以我不打扰你。"
这才是人类该干的活。把判断权交给更智能的工具，把时间留给真正需要处理的问题。
至于日常的依赖更新，Filippo 也觉得 Dependabot 的逻辑很扯淡。
为什么要跟着别人的发布周期走？应该按你的节奏来。
你可以在每次发版前统一更新依赖，而不是每天被 Dependabot 追着跑。
通过每天跑最新版测试，你能提前知道哪个依赖可能坑你，但不必急着合并。
这样做还有一个隐形好处：防供应链攻击。
很多恶意代码刚被植入依赖包时，生命周期很短。如果你不是第一时间自动拉取最新代码到生产环境，而是只在 CI 沙盒里跑一跑，风险就小得多。
把时间留给真正的战场
Filippo 这篇文章，其实是在给整个行业祛魅
Dependabot 这种工具，看起来是免费的午餐，实际上是在用你的注意力买单。
它用一种看似勤奋的方式，掩盖了工具本身在智能分析上的懒惰。
个人觉得，这不仅仅是工具的选择问题，更是工作流的哲学问题。
你是想做一个每天忙着合并 PR、却不知道自己在修什么的"按键侠"，还是想做一个掌控全局、只在关键时刻出手的"狙击手"？
Filippo 甚至在文末放了一张台伯河泛滥的照片。
隐喻：当河水（噪音）泛滥，淹没了熟悉的道路，我们需要的不是在那儿瞎扑腾，而是退后一步，找到真正安全的路径。
别再让工具把你变成机器人。关掉那个噪音机器，去写点真正的代码吧。
参考链接：
https://words.filippo.io/dependabot/