Turn Dependabot off

Original Article ↗ Hacker News Discussion ↗

Dependabot’s Limitations and Noise

  • Many commenters agree the core problem is version-level scanning: Dependabot flags any vulnerable version in the graph, regardless of whether the vulnerable code path is actually used.
  • This produces large volumes of low-value alerts, especially for:
    • Dev dependencies (build tools, test runners).
    • Client-only packages flagged for server-side issues.
    • ReDoS vulnerabilities in JS tooling that can’t be exploited in the app’s actual threat model.
  • Alert fatigue leads to auto-merging or ignoring alerts, which is viewed as less secure in practice.
  • Some use Dependabot mainly for scheduled, non-security updates and find that valuable; others find the PR and email spam intolerable.

Go’s govulncheck and Call-Graph-Based Approaches

  • govulncheck is widely praised: it traces call graphs and only reports vulnerabilities reachable from the code, drastically reducing false positives.
  • GitHub Actions around govulncheck (including PR annotations) are seen as a strong alternative to blind dependency bumping.
  • A key point from the article echoed in comments: security triage bandwidth exists only if you minimize false positives.

Other Ecosystems and Static Analysis Challenges

  • Rust: cargo-audit is mentioned but lacks govulncheck-style “vulnerable symbol reachability.” Lockfile quirks can surface unused deps.
  • JVM: OWASP Dependency-Check and Gradle/Sonatype tooling are cited.
  • Python: pip-audit and Bandit help but remain version-based; proper reachability depends on better metadata. Dynamic imports and idioms like getattr complicate analysis.
  • JS/TS: considered hardest; some commercial tools claim deep static analysis, but dynamic patterns and Express-style composition limit precision.

Operational & Compliance Pressures

  • SOC2, customer scanners, and platforms like Vanta treat open CVEs/Dependabot alerts as binary metrics, pushing teams to “fix the number” by merging updates they don’t understand.
  • Container scanners and base-image CVEs create similar noise, especially for unreachable or unused components.

Debate Over DoS/ReDoS CVEs

  • Long thread on whether DoS (especially ReDoS) should be treated as a “security vulnerability” at all versus an availability/operational concern.
  • Some argue most ReDoS CVEs are spam; others note that in certain architectures (e.g., fail-open controls, critical systems) DoS can translate into serious security impact.

Alternative Strategies

  • Scheduled manual audits (monthly/quarterly) plus ecosystem-specific tools instead of always-on bots.
  • Automated updates with cooldowns, strong tests, and sometimes canary deploys.
  • Testing against latest versions rather than constantly updating, and aggressively minimizing dependencies.