一名 Go 语言库维护者建议关闭 GitHub 的 Dependabot —— 这是一款用于自动保持代码仓库依赖项更新的工具。他认为，该工具会产生大量误报（false positives），从而“通过造成告警疲劳（alert fatigue）反而降低安全性”。
Filippo Valsorda 曾负责 Google 的 Go 安全团队，目前维护 Go 标准库中的加密相关包。上周，他为自己维护的一个库发布了安全修复：edwards25519 (Go library)，该库用于实现 EdDSA 加密算法。
然而，这次修复触发了 Dependabot 的自动流程，结果在大量实际上不受影响的代码仓库中生成了成千上万的 Pull Request。Valsorda 表示，这个自动流程还生成了一个他称为“毫无意义、凭空捏造的” Common Vulnerability Scoring System 评分，并向开发者提示仅有 73% 的兼容性评分，暗示有 27% 的概率会破坏代码。但实际上，这次修复只是“一个几乎没人使用的方法里的一行代码”。
很多项目之所以依赖这个库，是因为某个 Go 语言的 MySQL 数据库驱动使用了它。但该驱动并没有调用被修改的函数 MultiScalarMult，因此根本不会受到影响。基于这一点，Valsorda 将 Dependabot 称为一台“噪音机器”，并建议开发者直接关闭它。
Dependabot 最初是一个第三方工具，后来在 2019 年 5 月 被 GitHub 收购。它依赖 GitHub Advisory Database 的漏洞数据，在发现项目依赖包含已知漏洞时自动创建 Pull Request 和安全警报。
Valsorda 指出，Dependabot 既过于嘈杂，又不足以真正解决问题。
之所以“嘈杂”，是因为它似乎只检查项目是否存在某个依赖，而不会判断受影响的具体包是否真的被使用。他说：“任何像样的漏洞扫描器至少会根据实际使用的包进行过滤。”他还建议使用静态分析工具，例如用于 Go 生态的 govulncheck，它可以检测漏洞代码在项目中的可达性（reachability）。
另一方面，Dependabot 也不足以真正完成安全工作。Valsorda 表示，如果存在真实漏洞，就必须评估其影响，例如：
- 是否需要更新生产环境
- 是否需要轮换密钥
- 是否需要通知用户
如果开发者只是依赖 Dependabot 来处理依赖漏洞，那么他们的安全工作仍然远远不够。
除此之外，Valsorda 还不喜欢 Dependabot 的另一个功能：自动把依赖升级到最新版本。他认为，依赖更新应该按照项目自身的开发周期进行，而不是只要某个库发布新版本就立即升级。
快速升级同样存在风险——例如某个包被加入恶意代码。他建议在沙箱化的 CI（持续集成）环境中先测试更新后的依赖，以发现潜在问题，而不是直接更新生产代码。
在 Hacker News 上的相关讨论中，许多开发者对 Valsorda 的观点表示认同。不过，也有人指出，客户往往无法理解其中的细节。一条评论写道：
“客户会用这些工具扫描你的代码，他们不会接受‘我们从未调用那个函数’这种解释……这正是现实安全与我们为了安全而建立的流程开始严重脱节的地方。”
还有一种观点认为，Dependabot 的价值取决于是否有更好的替代方案。Go 生态在依赖安全检查方面已经相当完善，Valsorda 也列举了其他可用的工具和流程。但在一些资源有限、又缺乏明显替代方案的情况下，Dependabot 可能仍然比完全忽视依赖漏洞问题要好得多。
苏公网安备32021302001419号