FRESH

Hacker News

Home

Turn Dependabot off

641 points by todsacerdoti

by Chris_Newton

7 subcomments

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability.
One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.
Unlike those naïve tools, CodeQL seems to perform a real tracing analysis through the code, so its report doesn’t just say you have user-provided data being used dangerously, it shows you a complete, step-by-step path through the code that connects the input to the dangerous usage. This provides useful, actionable information to assess and fix real vulnerabilities, and it is inherently resistant to false positives.
Presumably there is still a possibility of false negatives with this approach, particularly with more dynamic languages like Python where you could surely write code that is obfuscated enough to avoid detection by the tracing analysis. However, most of us don’t intentionally do that, and it’s still useful to find the rest of the issues even if the results aren’t perfect and 100% complete.

by nfm

6 subcomments

The number of ReDoS vulnerabilities we see in Dependabot alerts for NPM packages we’re only using in client code is absurd. I’d love a fix for this that was aware of whether the package is running on our backend or not. Client side ReDoS is not relevant to us at all.

by ImJasonH

1 subcomments

Govulncheck is one of the Go ecosystem's best features, and that's saying something!
I made a GitHub action that alerts if a PR adds a vulnerable call, which I think pairs nicely with the advice to only actually fix vulnerable calls.
https://github.com/imjasonh/govulncheck-action
You can also just run the stock tool in your GHA, but I liked being able to get annotations and comments in the PR.
Incidentally, the repo has dependabot enabled with auto-merge for those PRs, which is IMO the best you can do for JS codebases.

by indiestack

2 subcomments

The govulncheck approach (tracing actual code paths to verify vulnerable functions are called) should be the default for every ecosystem, not just Go.
The fundamental problem with Dependabot is that it treats dependency management as a security problem when it's actually a maintenance problem. A vulnerability in a function you never call is not a security issue — it's noise. But Dependabot can't distinguish the two because it operates at the version level, not the call graph level.
For Python projects I've found pip-audit with the --desc flag more useful than Dependabot. It's still version-based, but at least it doesn't create PRs that break your CI at 3am. The real solution is better static analysis that understands reachability, but until that exists for every ecosystem, turning off the noisy tools and doing manual quarterly audits might actually be more secure in practice — because you'll actually read the results instead of auto-merging them.

by apitman

2 subcomments

I find dependabot very useful. It's drives me insane and reminds me of the importance of keeping dependencies to an absolute minimum.

by tracker1

3 subcomments

I kind of wish Dependabot was just another tab you can see when you have contributor access for a repository. The emails are annoying and I mostly filter, but I also don't want a bunch of stale PRs sitting around either... I mean it's useful, but would prefer if it was limited to just the instances where I want to work on these kinds of issues for a couple hours across a few repositories.

by 12_throw_away

2 subcomments

I'm a little hung up on this part:
> These PRs were accompanied by a security alert with a nonsensical, made up CVSS v4 score and by a worrying 73% compatibility score, allegedly based on the breakage the update is causing in the ecosystem.
Where did the CVSS score come from exactly? Does dependabot generate CVEs automatically?

by samhclark

4 subcomments

This makes sense to me. I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo.
Separately, I love the idea of the `geomys/sandboxed-step` action, but I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones. I'll give sandboxed-step a look, sounds like it would be a nice thing to keep in my toolbox.

by cedws

1 subcomments

I don’t know why the industry collectively accepted these security scanners (code + containers) that don’t even do the most basic of static analysis to see if the vulnerable code is reachable. Companies are breaking their backs trying to maintain a constant zero vulnerabilities in their container images when 99% of the CVEs don’t actually affect them anyway. The kicker is that updating the dependencies probably just introduces new CVEs to be discovered later down the line because most software does not backport fixes.

by woodruffw

0 subcomment

I think this is pretty good advice. I find Dependabot useful for managing scheduled dependency bumps (which in turn is useful for sussing out API changes, including unintended semver breakages from upstreams), but Dependabot’s built-in vulnerability scanning is strictly worse than just about every ecosystem’s own built-in solution.

by esafak

1 subcomments

I automate updates with a cooldown, security scanning, and the usual tests. If it passes all that I don't worry about merging it. When something breaks, it is usually because the tests were not good enough, so I fix them. The next step up would be to deploy the update into a canary cluster and observe it for a while. Better that than accrue tech debt. When you update on "your schedule" you still should do all the above, so why not just make it robust enough to automate? Works for me.

by solatic

0 subcomment

I sympathize with the author, and in principle I find myself nodding along with his prescriptions, but one of the benefits of Dependabot (and Renovate) are that they are language-agnostic. Depending on how many repositories, and how many languages, and upon whom the maintenance burden falls, there's a lot of value to be had. It may not really be feasible to add "the correct" CI workflows to every repository, and the alternative (nothing) inevitably ends up in repositories where dependencies have not been updated in years.
It's good optimization advice, if you have the time, or suffer enough from the described pain points, to apply it.

by jackfranklyn

0 subcomment

Dependabot works when you have a team that reviews PRs promptly and CI that catches breaking changes. For solo founders and tiny teams, those automated PRs pile up into noise and you stop reviewing them entirely. Then you've got 30 unmerged dependency bumps you're too scared to batch-merge.
What I do instead: monthly calendar reminder, run npm audit, update things that actually matter (security patches, breaking bugs), ignore patch bumps on stable deps. The goal isn't "every dep is always current" - it's "nothing in production has a known vulnerability". Very different targets.

by seg_lol

4 subcomments

Be wary of upgrading dependencies too quickly. This is how supply chain incursions are able to spread too quickly. Time is a good firwall.

by TZubiri

1 subcomments

Coming from someone with an almost ascetic dependency discipline, I look at some meta-dependencies as an outsider (dependabot, pnpm/yarn, poetry/venv/pipenv, snap/flatpak), a solution to too many dependencies that is yet another dependency, it feels like trying to get out of a hole by digging.
I think that for FOSS the F as in Gratis is always going to be the root cause of security conflicts, if developers are not paid, security is always going to be a problem, you are trying to get something out of nothing otherwise, the accounting equation will not balance, exploiting someone else is precisely the act that leaves you open to exploitation (only according to Nash Game Theory). "158 projects need funding" IS the vector! I'm not saying that JohnDoe/react-openai-redux-widget is going to go rogue, but with what budget are they going to be able to secure their own systems?
My advice is, if it ever comes the point where you need to install dependencies to control your growing dependency graph? consider deleting some dependencies instead.

by SamuelAdams

2 subcomments

What’s nice about Dependabot is that it works across multiple languages and platforms. Is there an equivalent to govulncheck for say NPM or Python?

by p1nkpineapple

1 subcomments

we struggle with a similar problem at my workplace - vuln alerts from GCP container image scans put a ton of noise into Vanta which screams bloody murder at CVEs in base images which we A) can't fix, and B) aren't relevant as they're not on the hot path (often some random dependency that we don't use in our app).
Are there any tools for handling these kind of CVEs contextually? (Besides migrating all our base images to chainguard/docker hardened images etc)

by andrewaylett

0 subcomment

I approve of Renovate's distinct recommendations for libraries vs applications.
For a library, you really want the widest range of "allowed" dependencies, but for the library's test suite you want to pin specific versions. I wrote a tool[1] that helps me make sure (for the npm ecosystem) my dependency specifications aren't over-wide.
For an application, you just want pinned specific dependencies. Renovate has a nice feature wherein it'll maintain transitive dependencies, so you can avoid the trap of only upgrading when forced to by more direct dependencies.
The net result is that most version bumps for my library code only affect the test environment, so I'm happy allowing them through if the tests pass. For application code, too, my personal projects will merge version bumps and redeploy automatically -- I only need to review if something breaks. This matches the implicit behaviour I see from most teams anyway, who rely on "manual review" but only actually succeed in adding toil.
My experience is that Renovate's lock file maintenance makes update a whole load safer than the common pattern of having ancient versions of most transitive dependencies then upgrading a thread of packages depended on by a newer version of a single dependency.
1: https://www.npmjs.com/package/downgrade-build

by mehagar

2 subcomments

Is there an equivalent for the JS ecosystem? If not, having Dependabot update dependencies automatically after a cooldown still seems like a better alernative, since you are likely to never update dependencies at all if it's not automatic.

by operator-name

1 subcomments

The custom Github Actions approach is very customisable and flexible. In theory you could make and even auto approve bumps.
If you want something more structured, I’ve been playing with and can recommend Renovate (no affiliation). Renovate supports far more ecosystems, has a better community and customisation.
Having tried it I can’t believe how relatively poor Dependabot, the default tool is something we put up with by default. Take something simple like multi layer dockerfiles. This has been a docker features for a while now, yet it’s still silently unsupported by dependabot!

by adamdecaf

0 subcomment

govulncheck is the much better answer and we use it.
We also let renovate[bot] (similar to dependabot) merge non-major dep updates if tests pass. I hardly notice when deps have small updates.
https://github.com/search?q=org%3Amoov-io+is%3Apr+is%3Amerge...

by notepad0x90

0 subcomment

I really think the developer community needs to learn the age-old skill of ignoring things. Don't treat things like dependabot, PRs,stars, issues,etc.. as a metric or quantifier of how good of a job you're doing with your code. Forget that social-drama nonsense.
I think the bigger problem is that Github is being treated as a quasi-social-media, and these things are being viewed as a "thumbs down" or "dislike" (and vice versa). Unless you have an SLA with someone, you don't have to meet any numbers, just do your best when you feel like it, and drive your project best way you think. Just don't be a dick to people about it, or react to these social-media metrics by lashing out against your users or supporters (not claiming that in this case!).

by robszumski

6 subcomments

We’ve built a modern dependabot (or works with it) agent: fossabot analyzes your app code to know how you use your dependencies then delivers a custom safe/needs review verdict per upgrade or packages groups of safe upgrades together to make more strategic jumps. We can also fix breaking changes because the agents context is so complete.
https://fossa.com/products/fossabot/
We have some of the best JS/TS analysis out there based on a custom static analysis engine designed for this use-case. You get free credits each month and we’d love feedback on which ecosystems are next…Java, Python?
Totally agree with the author that static analysis like govulncheck is the secret weapon to success with this problem! Dynamic languages are just much harder.
We have a really cool eval framework as well that we’ve blogged about.

by snowhale

0 subcomment

govulncheck is so much better for Go projects. it actually traces call paths so you only get alerted if the vulnerable function is reachable from your code. way less noise.

by bpavuk

1 subcomments

is there a `govulncheck`-like tool for the JVM ecosystem? I heard Gradle has something like that in its ecosystem.
search revealed Sonatype Scan Gradle plugin. how is it?

by KPGv2

1 subcomments

This is a symptom of JS culture, where people believe you must at all times and in all places have THE latest version of every library, and you MUST NOT wait more than a day to update your entire codebase accordingly.

by jgalt212

0 subcomment

The lead example is about the (*Point).MultiScalarMult method (not a golang person so perhaps wrong terminology).
Instead of, in addition to, updating all your dependencies, perhaps it would be better to emit monkey patches that turn unsafe methods into noops, or raise an exception if such methods are invoked. e.g "paste these lines at the beginning of main to ensure are you not impacted by CVE-2026-XXXX."

by 3form

0 subcomment

This reminds me that the vulnerability scanner at my company flagged every version of pandas because it has some function in the API that allows to run some equivalent of eval. Thankfully I have the ability to issue a waiver with "does not apply".

by 8bitme

0 subcomment

The issue with not updating often enough is that if there is a zero day and you're far enough behind you will be forced to go through the pain of working out how to upgrade to the latest patched version where there may be a painful upgrade path in between

by arianvanp

1 subcomments

At this point your steps are so simple id skip GitHub actions security tyre fire altogether. Just run the go commands whilst listening on GitHub webhooks and updating checks with the GitHub checks API.
GitHub actions is the biggest security risk in this whole setup.
Honestly not that complicated.

by fulafel

0 subcomment

Alert fatigue has been long identified and complained about, this is just a new kind of that. But it's hitting a different set of people.

by literallyroy

0 subcomment

The go ecosystem is pretty good about being backwards compatible. Dependabot regular update prs once a week seems like a good option in addition to govulncheck.

by NewJazz

0 subcomment

Besides go, what languages have this type of fidelity for vulnerability scope. Python? Node? Rust?

by focusedmofo

0 subcomment

Is there an equivalent for JS/TS?

by hokkos

0 subcomment

Most CVE now are pure spam without value, all I get is dev dependencies affected by regex that could take too long, scanner should do a better job to differentiate between dependencies and dev dependencies.

by maelito

1 subcomments

Better : leave github for Codeberg.

by indiekitai

0 subcomment

The core problem is that Dependabot treats dependency graphs as flat lists. It knows you depend on package X, and X has a CVE, so it alerts you. But it has no idea whether you actually call the vulnerable code path.
Go's tooling is exceptional here because the language was designed with this in mind - static analysis can trace exactly which symbols you import and call. govulncheck exploits this to give you meaningful alerts.
The npm ecosystem is even worse because dynamic requires and monkey-patching make static analysis much harder. You end up with dependency scanners that can't distinguish between "this package could theoretically be vulnerable" and "your code calls the vulnerable function."
The irony is that Dependabot's noise makes teams less secure, not more. When every PR has 12 security alerts, people stop reading them. Alert fatigue is a real attack surface.

by newzino

0 subcomment

The part that kills me is the compliance side. SOC2 audits and enterprise security reviews treat "open Dependabot alerts" as a metric. So teams merge dependency bumps they don't understand just to get the count to zero before the next audit. That's actively worse for security than ignoring the alerts.
govulncheck solves this if your auditor understands it. But most third-party security questionnaires still ask "how do you handle dependency vulnerabilities?" and expect the answer to involve automated patching. Explaining that you run static analysis for symbol reachability and only update when actually affected is a harder sell than "we merge Dependabot PRs within 48 hours."

by clarabennett26

0 subcomment

[dead]

by aswihart

0 subcomment

> Dependencies should be updated according to your development cycle, not the cycle of each of your dependencies. For example you might want to update dependencies all at once when you begin a release development cycle, as opposed to when each dependency completes theirs.
We're in this space and our approach was to supplement Dependabot rather than replace it. Our app (https://www.infield.ai) focuses more on the project management and team coordination aspect of dependency management. We break upgrade work down into three swim lanes: a) individual upgrades that are required in order to address a known security vulnerability (reactive, most addressed by Dependabot) b) medium-priority upgrades due to staleness or abandonedness, and c) framework upgrades that may take several months to complete, like upgrading Rails or Django. Our software helps you prioritize the work in each of these buckets, record what work has been done, and track your libyear over time so you can manage your maintenance rotation.