Go maintainer slams GitHub's Dependabot as 'noise machine' that floods repos with false alerts

A prominent Go library maintainer has called for developers to disable GitHub's Dependabot, arguing that the automated dependency-scanning tool is creating more problems than it solves by flooding repositories with false alerts and misleading security scores.

Filippo Valsorda, who maintains the cryptography packages in the Go standard library and previously led Google's Go security team, published a scathing critique of Dependabot after the tool generated thousands of pull requests against repositories that weren't actually vulnerable to a security fix he had released.

The 'noise machine' problem

The incident began when Valsorda published a security fix for his filippo.io/edwards25519 library, which implements EdDSA (Edwards-curve Digital Signature Algorithm) cryptography. The fix involved changing just one line in a method that Valsorda noted "no one uses."

Despite this, Dependabot opened thousands of pull requests against unaffected repositories. The tool also generated what Valsorda called "a nonsensical made up CVSS v4 score" and warned developers of a 73 percent compatibility score, implying a 27 percent chance of breaking code—even though the change was minimal and unlikely to cause issues.

The most common reason for depending on this library is that a Go MySQL database driver uses it, but since this driver doesn't call the amended function (MultiScalarMult), it's not affected by the vulnerability.

"Dependabot is a noise machine," Valsorda wrote, recommending that developers turn it off entirely.

Why Dependabot fails at security

Valsorda identified two fundamental problems with Dependabot's approach to dependency security:

Too noisy, not precise enough: The tool appears to check only whether a dependency exists, not whether the impacted function or code path is actually used. "Any decent vulnerability scanner will at the very least filter based on the package," he said.

Insufficient for real security work: Even when Dependabot correctly identifies a vulnerability, it doesn't help with the actual security response. "A real vulnerability should be assessed for its impact: production might need to be updated, secrets rotated, users notified," Valsorda explained. Relying solely on Dependabot to manage dependency vulnerabilities means developers aren't doing enough.

Instead of Dependabot, Valsorda recommends using static analysis tools like govulncheck (for Go vulnerabilities) that can identify whether a flaw is actually reachable in the code.

The update dilemma

Beyond security scanning, Valsorda also criticized Dependabot's feature for keeping dependencies up to date with the latest versions. He argues that dependencies should be updated according to the project's development cycle, not whenever a new version appears.

Updating quickly carries risks, particularly if malicious code has been added to a package. Valsorda recommends testing updated packages in a sandboxed continuous integration process to discover any problems without updating production code.

Community response and context

The critique sparked widespread agreement on Hacker News, though some noted that customers may not understand the nuances. "Customers will scan your code with these tools and they won't accept 'we never call that function' as an answer... this is where actual security starts to really diverge from the practices we've developed in the name of security," one commenter observed.

However, the value of Dependabot varies significantly depending on the ecosystem and available alternatives. The Go ecosystem is particularly well-equipped for dependency checking, with robust tools and processes that developers can use instead. In other cases, when resources are limited and there's no obvious alternative, Dependabot is likely better than ignoring the problem entirely.

The broader implications

This critique highlights a fundamental tension in modern software development: the balance between automated security tools and human judgment. While tools like Dependabot aim to make security more accessible and systematic, they can also create noise that obscures real threats and wastes developer time.

The incident also underscores the importance of understanding how security tools work and their limitations. A tool that generates thousands of alerts for non-issues can be worse than no tool at all, as it leads to "alert fatigue" where developers start ignoring all warnings, including legitimate ones.

For maintainers and developers, Valsorda's advice suggests a more thoughtful approach to dependency management: use precise, context-aware tools for security scanning, update dependencies deliberately as part of your development cycle, and don't rely on automated tools to do the critical thinking required for real security work.

The debate around Dependabot reflects broader questions about the role of automation in software security and the trade-offs between convenience and accuracy in development tools.