Turn Dependabot Off

The article presents a compelling critique of Dependabot as a security and dependency management tool, particularly within the Go ecosystem. The author, Filippo Valsorda, positions Dependabot not as a helpful assistant but as a "noise machine" that creates the illusion of productivity while actually generating significant friction in development workflows.

The central thesis emerges from a concrete case study involving a vulnerability in the filippo.io/edwards25519 package. When the author published a security fix for the (*Point).MultiScalarMult method, Dependabot responded by opening thousands of pull requests across repositories that were entirely unaffected by this specific vulnerability. These PRs were accompanied by misleading security alerts, including a "nonsensical" CVSS v4 score and an alarming 73% compatibility score that inaccurately suggested widespread breakage. The situation became particularly absurd when the Wycheproof repository received alerts despite only importing the unaffected filippo.io/edwards25519/field package, not the vulnerable filippo.io/edwards25519 package.

This case study illustrates a fundamental problem with Dependabot's approach: it lacks the contextual understanding to distinguish between actual security threats and irrelevant updates. The author contrasts this with the Go Vulnerability Database, which contains rich metadata including specific vulnerable symbols, packages, and versions. This granular information enables more sophisticated filtering that can determine whether a vulnerability actually affects a given codebase.

The author demonstrates how govulncheck, a tool from the Go ecosystem, implements this more intelligent approach. By performing static analysis to determine whether vulnerable code paths are actually reachable, govulncheck successfully identified that the author's project was not affected by the edwards25519 vulnerability, despite indirectly depending on the package. This represents a significant improvement over Dependabot's package-level scanning, which generates false positives at scale.

The article proposes a concrete replacement for Dependabot through two scheduled GitHub Actions:

1. A daily govulncheck scan that only triggers alerts when actual vulnerabilities are found
2. A test suite that runs against both locked and latest dependency versions

This approach maintains the benefits of early detection of compatibility issues without the noise of unnecessary updates. The author suggests that dependencies should be updated according to a project's development cycle, not the release cycle of each dependency. Running tests against the latest versions without actually updating them allows teams to defer updates to more appropriate times while still catching potential issues early.

The implications of this critique extend beyond individual developer productivity. The author highlights how false positive alerts contribute to alert fatigue, making it increasingly difficult to prioritize actual security threats. This phenomenon creates a dangerous security paradox where the tool intended to improve security ultimately undermines it by overwhelming developers with irrelevant information.

Furthermore, the article points out the external costs imposed on open source maintainers who receive constant, unfounded requests to update dependencies. This represents a significant burden on the open source ecosystem, diverting maintainer attention from substantive contributions to administrative tasks.

The author addresses potential counterarguments by acknowledging the legitimate need to prevent exploitation of vulnerabilities while demonstrating how automated tools can effectively filter noise. They also respond to the argument that Dependabot helps maintain updated dependencies by proposing an alternative approach that provides the benefits of early compatibility detection without the drawbacks of premature updates.

The article concludes with practical implementation details, including GitHub Action configurations and even a recommendation for CI sandboxing using tools like geomys/sandboxed-step to mitigate supply chain attack risks. This comprehensive approach represents a thoughtful alternative to the current state of automated dependency management.

For those interested in implementing the author's suggestions, the GitHub Actions code snippets provide a starting point for replacing Dependabot with a more effective workflow. The govulncheck tool can be found at golang.org/x/vuln/cmd/govulncheck, and the sandboxed-step action is available at geomys/sandboxed-step.

The author's perspective carries particular weight given their experience as former lead of the Go Security Team (2020-2021), during which they advocated for the very approach they now recommend. This background lends credibility to their critique and their proposed solutions.

The article represents a thoughtful examination of the trade-offs in automated dependency management, advocating for a more nuanced approach that balances security concerns with developer productivity and ecosystem sustainability.