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.
> 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.
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.
> 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.
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
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..."
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.
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.
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.
I started to reevaluate the seriousness of this advice with the going to jail prompt. I probably should have caught on sooner :)
How did you reach "Set open-pull-requests-limit to zero" and not recognize this as satire?
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
seems the easiest way is to switch from Microslop GitHub to another platform
Excellent troll post. I've had a good chuckle.