Go语言库维护者批评GitHub的Dependabot是"噪音制造机"

一位Go语言库维护者呼吁开发者关闭GitHub的Dependabot功能，认为这个依赖扫描工具产生的误报会"因警报疲劳而降低安全性"。

曾负责Google Go安全团队的Filippo Valsorda，目前维护着Go标准库中的加密包。上周，他为自己维护的库filippo.io/edwards25519发布了一个安全修复，该库用于EdDSA（Edwards曲线数字签名算法）加密。结果，Dependabot针对"未受影响的代码库开启了数千个拉取请求"，Valsorda表示。

这个自动化流程还生成了Valsorda所称的"毫无意义的虚构CVSS v4评分"，并警告开发者兼容性评分为73%，暗示有27%的代码破坏风险，尽管修复只是"在无人使用的方法中修改了一行代码"。

依赖这个库最常见的原因是Go MySQL数据库驱动程序使用了它，但由于并未调用被修改的函数（MultiScalarMult），因此不受影响。Valsorda称GitHub这个工具是"噪音制造机"，建议将其关闭。

Dependabot最初是第三方工具，GitHub于2019年5月收购了它。它使用GitHub咨询数据库中的数据，在包含已列出漏洞依赖项的代码库中自动生成拉取请求和安全警报。

Valsorda表示，Dependabot既过于嘈杂，又无法充分发挥其用途。说它过于嘈杂，是因为它似乎只检查依赖项是否存在，而不检查受影响的函数或代码路径是否真正被使用。

"任何像样的漏洞扫描器至少都会基于包进行过滤，"他说。此外，他建议使用像govulncheck这样的静态分析工具（针对Go漏洞情况），它能识别缺陷的可达性。

Valsorda补充说，尽管存在噪音问题，Dependabot也是不够的，因为真正的漏洞"应该评估其影响：生产环境可能需要更新，密钥需要轮换，用户需要通知"。如果开发者依赖Dependabot来管理依赖漏洞，那么他们做得还不够。

Valsorda还不喜欢Dependabot的另一个功能：保持依赖项更新到最新版本。他认为依赖项应该根据项目的开发周期进行更新，而不是每当包出现新版本时就更新。如果恶意代码被添加到包中，快速更新也会带来一些风险。

他建议在沙箱化的持续集成过程中测试更新的包，以便在不更新生产代码的情况下发现任何问题。

Hacker News上关于这个话题的讨论发现人们普遍同意Valsorda的观点，尽管客户可能不理解其中的细节。

"客户会用这些工具扫描你的代码，他们不会接受'我们从未调用过那个函数'这样的答案……这就是实际安全性开始真正偏离我们以安全名义开发的实践的地方，"一条评论说。

也有观点认为，Dependabot的价值因其替代方案而异。Go生态系统在依赖检查方面设置得很好，Valsorda描述了开发者可以使用的其他工具和流程。在其他情况下，当资源有限且没有明显替代方案时，Dependabot可能比忽略它所解决的问题要好。

Q&A

Q1：Dependabot是什么工具？

A：Dependabot是GitHub收购的依赖扫描工具，最初是第三方工具，2019年5月被GitHub收购。它使用GitHub咨询数据库中的数据，在包含已列出漏洞依赖项的代码库中自动生成拉取请求和安全警报。

Q2：Filippo Valsorda为什么批评Dependabot？

A：Valsorda认为Dependabot既过于嘈杂又功能不足。它只检查依赖项是否存在，不检查受影响的函数是否真正被使用，导致大量误报。同时它无法充分评估真正漏洞的影响，不能替代完整的安全评估流程。

Q3：有什么替代Dependabot的更好方案？

A：Valsorda建议使用静态分析工具如govulncheck来识别漏洞的可达性，这类工具至少会基于包进行过滤。同时建议在沙箱化的持续集成过程中测试更新的包，根据项目开发周期而不是包更新频率来管理依赖项更新。