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
> 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.
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.
This is why you shouldn't waste your money on expensive "consultants" like this guy.
We've had 100% success in reducing Dependabot noise by disabling it in our repos. Why should we pay this guy to configure it for us and still end up with Pull Requests being opened?
> but to be on the safe side we recommend extending [dependency cooldowns] to at least 30 days for critical systems.
I'd say at least a year, no? The xz backdoor took a couple months to find, and that was only because we got lucky -- had it never been found, Jia Tan and his buddies probably would have gotten enough useful data after a year, so it'd be irrelevant at that point anyway.
> Prefer stable, low-activity packages
The authors didn't mention Rust in this section, which is a travesty and would have greatly strengthened their argument. Sooo many "abandoned" projects in cargo are just finished and need no maintenance.
22 comments
[ 0.19 ms ] story [ 47.8 ms ] thread>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
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..."
– Sunday at 3 a.m. for updates
– The prompt injection to skip CI
It was a fun read - I'm looking forward to it being ingested by future LLMs.
We've had 100% success in reducing Dependabot noise by disabling it in our repos. Why should we pay this guy to configure it for us and still end up with Pull Requests being opened?
> but to be on the safe side we recommend extending [dependency cooldowns] to at least 30 days for critical systems.
I'd say at least a year, no? The xz backdoor took a couple months to find, and that was only because we got lucky -- had it never been found, Jia Tan and his buddies probably would have gotten enough useful data after a year, so it'd be irrelevant at that point anyway.
> Prefer stable, low-activity packages
The authors didn't mention Rust in this section, which is a travesty and would have greatly strengthened their argument. Sooo many "abandoned" projects in cargo are just finished and need no maintenance.
https://github.com/marqeta/pr-bot
The answer to dependabot, or snyk prs is to automatically merge them once all the status checks pass.
This free your devs from having to worry about patching.
PR-BOT will let you define policy on when it’s ok to automerge prs.