16 Best Practices for Reducing Dependabot Noise

(nesbitt.io)

12 points | by zdw 6 days ago ago

9 comments

  • lanyard-textile an hour ago 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..."

  • anishgupta 6 days ago 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

  • williamjackson an hour ago 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?
  • torton an hour ago ago

    Excellent troll post. I've had a good chuckle.

  • doodlesdev an hour ago 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.
    • equinumerous an hour ago 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.

    • wirelesspotat an hour ago 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.

    • lanyard-textile an hour ago ago

      I started to reevaluate the seriousness of this advice with the going to jail prompt. I probably should have caught on sooner :)

    • williamjackson an hour ago 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.