Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turn Dependabot off

words.filippo.io

Post reply on HN
Print view View original

11–20 of 195 posts

Re: Turn Dependabot off

#11

Post by jamietanna »

esafak wrote: post #8
seg_lol wrote: post #5

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

They fixed that last summer: https://github.blog/changelog/2025-07-01-dependabot-supports...

Yep, and we've had it for a while in Renovate too: https://docs.renovatebot.com/key-concepts/minimum-release-ag...

(I'm a Renovate maintainer)

(I agree with Filippo's post and it can also be applied to Renovate's security updates for Go modules - we don't have a way, right now, of ingesting better data sources like `govulncheck` when raising security PRs)

Re: Turn Dependabot off

#12

Post by esafak »

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.

Re: Turn Dependabot off

#13

Post by ImJasonH »

seg_lol wrote: post #5

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

Here's a Go mod proxy-proxy that lets you specify a cooldown, so you never get deps newer than N days/weeks/etc

https://github.com/imjasonh/go-cooldown

It's not running anymore but you get the idea. It should be very easy to deploy anywhere you want.

Re: Turn Dependabot off

#16

Post by conradludgate »

samhclark wrote: post #2

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.

https://rustsec.org/

Re: Turn Dependabot off

#17

Post by nfm »

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.

Re: Turn Dependabot off

#18

Post by mehagar »

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.

Re: Turn Dependabot off

#19

Post by FiloSottile »

esafak wrote: post #12

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 abo…

For regular updates, because you can minimize but not eliminate risk. As I say in the article that might or might not work for your requirements and practices. For libraries, you also cause compounding churn for your dependents.

For security vulnerabilities, I argue that updating might not be enough! What if your users’ data was compromised? What if your keys should be considered exposed? But the only way to have the bandwidth to do proper triage is by first minimizing false positives.

Post reply on HN