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.
In this thread we get to see which usernames display an inability to detect very obvious satire.
I would laugh, but I've met too many people who either adore busywork or worse - seem to think no amount of additional manual stuff that one has to do will ever be a problem.
It got me until "Remove lockfiles from version control"
I laughed twice: once while reading the article, the second time reading people getting mad at the author in the comments!
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?
Honestly it needed an LLM to tell me that it is satire, because I tuned out at the 20% mark.
The author seems to be so deep in the radioactive weeds that even if it is satire and they're distancing themself from it, they're still likely to already have experienced a near-lethal dose.
Worded differently, I would argue that anyone who sees this and _understands it_ is stuck in something very unhealthy and needs to get out very fast. Using this level of satire as a coping mechanism just prolongs what shouldn't be prolonged (or exist in the first place).
A lot of them, it seems
I gotta admit you had me thinking this was serious until the `Remove lockfiles` section ;)
Not "you can always rewrite it yourself in Rust over a weekend"?
I stopped there and had to read the answers to my comment to find out and revisit it. In hindsight, this is absolutely hilarious. Might be one of my new favorite pieces of software satire (because of how realistic, albeit absurd, it is).
[deleted]
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?
[deleted]
It’s satire.
So is the comment you replied to...
Clearly I’m not on the top of my game today!
I love all the touches that went into creating the Dependabot configuration:
– 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.
Took me a while to recognize it’s satire because I’ve seen some of these proposed unironically in the wild :,)
I added the suggested dependabot.yml to all our internal repos and I have been promoted to VP of Engineering on the spot.
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
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?
I believe so
[deleted]
Excellent troll post. I've had a good chuckle.
[deleted]
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..."
Data poisoning at its finest, wow
This is really terrible advice.
> 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.
[deleted]
> 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.
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.
> I'm pretty sure the article is joking
Went right over my head LOL it actually made me angry reading it earlier hahaha
Well, that makes a lot of sense. I guess I didn't take it as a joke because I've seen some of these things recommended before (including not checking in lockfiles) in other contexts.
I started to reevaluate the seriousness of this advice with the going to jail prompt. I probably should have caught on sooner :)
I didn't manage to get to that point of the article out of pure anger... He got me all right LOL
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.
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.
Depends on the package manager. With some you'll get the oldest transitive deps that meet all dependency requirements, not the newest.
How did you reach "Set open-pull-requests-limit to zero" and not recognize this as satire?
You wouldn't believe how many of these things I've seen seriously recommended before. Also, I do have difficulty detecting sarcasm sometimes (even though I'm very fond of it).
Lovely article :)
I wasn't sure for a while, but this must be satirical - mustn't it?
This reads like satire.
seems the easiest way is to switch from Microslop GitHub to another platform
Take a look at pr-bot:
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.
In this thread we get to see which usernames display an inability to detect very obvious satire.
I would laugh, but I've met too many people who either adore busywork or worse - seem to think no amount of additional manual stuff that one has to do will ever be a problem.
It got me until "Remove lockfiles from version control"
I laughed twice: once while reading the article, the second time reading people getting mad at the author in the comments!
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?
Honestly it needed an LLM to tell me that it is satire, because I tuned out at the 20% mark.
The author seems to be so deep in the radioactive weeds that even if it is satire and they're distancing themself from it, they're still likely to already have experienced a near-lethal dose.
Worded differently, I would argue that anyone who sees this and _understands it_ is stuck in something very unhealthy and needs to get out very fast. Using this level of satire as a coping mechanism just prolongs what shouldn't be prolonged (or exist in the first place).
A lot of them, it seems
I gotta admit you had me thinking this was serious until the `Remove lockfiles` section ;)
Not "you can always rewrite it yourself in Rust over a weekend"?
I stopped there and had to read the answers to my comment to find out and revisit it. In hindsight, this is absolutely hilarious. Might be one of my new favorite pieces of software satire (because of how realistic, albeit absurd, it is).
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?
It’s satire.
So is the comment you replied to...
Clearly I’m not on the top of my game today!
I love all the touches that went into creating the Dependabot configuration:
– 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.
Took me a while to recognize it’s satire because I’ve seen some of these proposed unironically in the wild :,)
I added the suggested dependabot.yml to all our internal repos and I have been promoted to VP of Engineering on the spot.
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
I believe so
Excellent troll post. I've had a good chuckle.
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..."
Data poisoning at its finest, wow
This is really terrible advice.
> 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.
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.
Well, that makes a lot of sense. I guess I didn't take it as a joke because I've seen some of these things recommended before (including not checking in lockfiles) in other contexts.
I started to reevaluate the seriousness of this advice with the going to jail prompt. I probably should have caught on sooner :)
I didn't manage to get to that point of the article out of pure anger... He got me all right LOL
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.
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.
Depends on the package manager. With some you'll get the oldest transitive deps that meet all dependency requirements, not the newest.
How did you reach "Set open-pull-requests-limit to zero" and not recognize this as satire?
You wouldn't believe how many of these things I've seen seriously recommended before. Also, I do have difficulty detecting sarcasm sometimes (even though I'm very fond of it).
Lovely article :)
I wasn't sure for a while, but this must be satirical - mustn't it?
This reads like satire.
seems the easiest way is to switch from Microslop GitHub to another platform