Okay, maybe this is a silly question, but I've been using Dependabot on my Shopify app project for a few months now and I'm starting to feel a bit... frustrated? 😅
It keeps opening PRs to bump versions of direct dependencies in my `package.json`, which is great! I can review those. But for the *transitive* ones—the dependencies of my dependencies—the PRs often feel useless. The fix is usually to update the *parent* package, not the vulnerable nested one directly. So Dependabot creates this PR that I can't really act on, or that even breaks things if I merge it, because it's trying to patch a library three levels down.
Example: last week it flagged a vulnerability in `lodash` (a sub-dependency of a sub-dependency). The PR tried to bump a deep nested version, but the actual fix required updating a totally different top-level package to a newer version that used a safe `lodash`. I spent an hour figuring that out.
Am I using it wrong? Is this just how it is? I see all these automated PRs and feel like I'm "doing security," but for transitive stuff, it seems like it's mostly noise that makes me feel overwhelmed. Should I just be ignoring those alerts and focusing on the direct dependency updates? How do you all handle this?
That lodash example perfectly illustrates the core limitation. Dependabot operates at the version constraint level it can see in your lockfile, not the semantic dependency tree. When it sees a vulnerable `lodash@4.17.15` pinned deep in `package-lock.json`, its only recourse is to try and bump that specific instance, which often conflicts with the parent package's own version constraint.
You're not using it wrong. The noise for transitive dependencies is a known trade-off. Its value isn't in providing merge-ready fixes for those deep vulnerabilities, but in forcing the issue onto your radar. The alert tells you that to resolve it, you must either:
* Update the top-level package that's pulling in the old version (as you found).
* Use an override or resolution in your package manager, if supported, to force the newer version.
* Accept the risk and dismiss the alert.
The overhead of investigating each one is real, but I've found it's still less work than manually auditing the dependency tree for vulnerabilities on a schedule.
Data over dogma
"Forcing the issue onto your radar" sounds nice until you're dealing with a dozen of these a week. The overhead is real, and it's mostly wasted because the actionable path is almost always the same: bump the top-level package.
The trade-off isn't just noise, it's a distraction that pulls you away from real security work to process a non-actionable alert. The time spent investigating the PR, realizing you can't merge it, and then finding the root cause is more than if the tool just reported the root cause directly.
The real cost is the complacency it breeds. Teams start rubber-stamping "close PR, update parent lib later" and later never comes.