16 Best Practices for Reducing Dependabot Noise
29 points
by zdw
5 days ago
| 9 comments
| nesbitt.io
| HN
vlovich123
1 hour ago
[-]
In this thread we get to see which usernames display an inability to detect very obvious satire.
reply
wiether
36 minutes ago
[-]
I laughed twice: once while reading the article, the second time reading people getting mad at the author in the comments!
reply
odo1242
33 minutes ago
[-]
A lot of them, it seems
reply
zahlman
37 minutes ago
[-]
Presumably there are also people who simply disagree with the message being delivered through the satire... ?

... Or conclude that the message is contradictory such that it's basically just trolling?

reply
AdrienPoupa
30 minutes ago
[-]
I gotta admit you had me thinking this was serious until the `Remove lockfiles` section ;)
reply
anishgupta
5 days ago
[-]
Had fun reading this, pretty well written. >Consolidate into a monorepo lol this sounds like as if you make a dog tired by playing with it so it sleeps which you're gone :'D

>Contextualize the actual risk This is not as easy as it seems, for example reflection cases where runtime behavior affects a package usage. example: const lib = require(process.env.PARSER) lib.parse(userInput) could use a safe parser in production or a vulnerable one in another environment, but from a code level perspective there's no certainity which package is actually used

reply
williamjackson
2 hours ago
[-]

    At sufficient scale, Dependabot’s analysis will time out before completing, effectively rate-limiting the number of PRs it can generate. This natural throttling prevents notification fatigue while maintaining the appearance of active security tooling.
Am I being trolled?
reply
lanyard-textile
2 hours ago
[-]
Denial: "These dependabot MRs aren't even fixing real security issues, these do not exist in the wild."

Bargaining: "Okay we'll fix them but we'll do it on a schedule, so that it doesn't interrupt sprints."

Anger: "Okay let's just yoink the package lock file how about that?"

Depression: [skip ci]

Acceptance: "So apparently copilot can do this..."

reply
doodlesdev
3 hours ago
[-]

   > Modern languages like Zig, Gleam, and Roc offer genuine productivity benefits and attract top talent. As a bonus, their ecosystems are young enough that security tooling has not caught up yet. Dependabot will add support eventually, but until then you get the best of both worlds: a modern stack and a quiet PR queue.
How the hell is that actually a good thing? You might as well just use another language and disable Dependabot security updates if that's what you're looking for. Dependabot security updates aren't a liability, they're an asset in a world where developers use hundreds of dependencies daily, where every few months one of them is going to have a XSS or RCE vulnerability that has to be patched ASAP.

   > And if you are really concerned about a dependency’s security, you can always rewrite it yourself in Rust over a weekend.
That's not how it works. Honestly, this blog post gets me really worried about this developer's projects and clients.

   > Remove lockfiles from version control
What the fuck.
reply
williamjackson
3 hours ago
[-]
Thank you for expressing my thoughts as well. The article seems to be full of contradictory “advice”.

Use a dependency cooldown, okay … but don’t commit your lockfile so you are always running the latest transitive deps? That’s nuts.

reply
Uvix
1 hour ago
[-]
Depends on the package manager. With some you'll get the oldest transitive deps that meet all dependency requirements, not the newest.
reply
equinumerous
3 hours ago
[-]
The "> Remove lockfiles from version control" got me as well.

> Reproducible builds sound nice in theory, but velocity matters more than determinism. Think of it as chaos engineering for your dependency tree.

Reproducible builds are nice in practice, too. :) In the Node.js ecosystem, if you have enough dependencies, even obeying semver your dependencies will break your code. Pinning to specific versions is critical.

reply
lanyard-textile
2 hours ago
[-]
I started to reevaluate the seriousness of this advice with the going to jail prompt. I probably should have caught on sooner :)
reply
wirelesspotat
3 hours ago
[-]
I'm pretty sure the article is joking

> If the vulnerability were critical, someone would have merged it by now.

> GitHub Copilot can automatically suggest fixes for security vulnerabilities. Instead of updating to a patched version, let AI generate a workaround in your own code.

reply
yunwal
1 hour ago
[-]
How did you reach "Set open-pull-requests-limit to zero" and not recognize this as satire?
reply
torton
2 hours ago
[-]
Excellent troll post. I've had a good chuckle.
reply
jbreckmckye
1 hour ago
[-]
I wasn't sure for a while, but this must be satirical - mustn't it?
reply
blibble
1 hour ago
[-]
seems the easiest way is to switch from Microslop GitHub to another platform
reply