Dependabot comes enabled by default on GitHub repositories. It feels like the right thing to do, after all, who doesn't want security monitoring for their dependencies?

But there's a problem: Dependabot creates noise, not signal.

I disabled Dependabot on my active Laravel project. And I believe I'm more secure for it.

The illusion of security

When Dependabot is enabled by default, it sends a subtle message: "This tool is monitoring your repository, so you're safe." It feels like responsible engineering. It feels like checking a box that says "we take security seriously."

But the reality is different. Instead of reducing my workload, Dependabot increased it. I received security alerts that, after careful investigation, were completely irrelevant to my project. Each alert either wasted my time investigating, or trained me to ignore it.

Neither outcome is good.

A security tool that can't distinguish between real threats and noise isn't helping; it's hurting. It's creating alert fatigue, which is dangerous: when developers learn to ignore warnings, they'll ignore the real threats too.

Real-world false positives

Example 1: PHPUnit coverage vulnerability

Today I received a critical Dependabot alert about PHPUnit. The vulnerability described a "poisoned pipeline execution" attack, where malicious code could execute through code coverage files. The alert explained:

"This vulnerability requires local file write access to the location where PHPUnit stores or expects code coverage files for PHPT tests. This can occur through CI/CD Pipeline Attacks, Local Development Environment, or Compromised Dependencies."

The alert sounded serious. It mentioned "critical context" and warned about running test suites from unreviewed pull requests.

But here's the thing: I don't run PHPUnit in production. I don't run PHPUnit in any CI/CD pipeline. I only run it locally during development.

I spent an hour reading through the vulnerability details, tracing through how PHPUnit stores coverage files, and confirming what I already knew: this vulnerability doesn't affect my production application. It's a local development concern, not a production security risk.

I wasted an hour investigating what I already knew.

Example 2: npm security alerts for build dependencies

I have the same problem with npm security alerts. My Laravel project uses npm only for building CSS and JavaScript assets via Vite. These dependencies, webpack, PostCSS, CSS parsers, etc., run during the build process, producing static assets that are deployed to production. None of this code executes in the browser or on the server.

Yet Dependabot and npm audit regularly flood my inbox with vulnerabilities for these build-only dependencies. Regular Expression Denial of Service vulnerabilities in CSS parsers. ReDoS issues in dependency resolvers. "High severity" alerts for code that never runs in production.

I either waste time investigating them, or I learn to ignore them.

Neither is good security practice.

I'm not alone in this

I'm not imagining this problem. In 2021, Dan Abramov, a React core team member, published "npm audit: Broken by Design." He reviewed every npm audit issue reported to his team over several months and found something striking:

"I've spent several hours looking through every npm audit issue reported to us over last several months, and they all appear to be false positives in context of a build tool dependency like Create React App."

His examples mirror mine:

browserslist (ReDoS vulnerability) - requires an attacker to modify your local package.json configuration. If an attacker can modify files on your machine, you have bigger problems than a slow regular expression.
glob-parent - only used in webpack-dev-server for local file watching. None of this logic leaves your development machine.
css-what - a CSS parser used during the build process to optimize stylesheets. If an attacker can modify your source code, they'll do something worse than slow down your build.

Abramov described this as "security theater" that "wastes person-decades of effort." But most importantly, he warned:

"Someday, it will make our users miserable because we have trained an entire generation of developers to either not understand warnings due to being overwhelmed, or to simply ignore them because they always show up."

This is exactly my fear.

The core problem: Security tools lack context

Dependabot and similar tools scan your composer.json and package.json files and cross-reference them with vulnerability databases. That's valuable; but it's incomplete.

Here's what Dependabot doesn't know about my project:

Which dependencies run in production vs. only in builds: My Laravel app uses a handful of npm packages for asset compilation. None of them execute in production. Dependabot treats them identically to dependencies that actually run on my servers.
Which vulnerabilities are exploitable in my context: A ReDoS vulnerability in a CSS parser is only a problem if an attacker can supply malicious CSS input to that parser. In my Laravel application, I control all CSS; it's written by me. An attacker can't inject CSS.
My testing and deployment practices: I don't run PHPUnit in CI/CD. I don't allow unreviewed pull requests to execute code. The PHPUnit vulnerability requires specific conditions I don't have.
My dependency hygiene: I regularly update dependencies and run my test suite. I'm not accumulating a backlog of outdated packages.

Vulnerabilities are abstract; impact is concrete. A tool that can't distinguish between the two creates noise.

GitHub themselves acknowledge this

GitHub recognizes this limitation. In July 2022, they paused Dependabot malware notifications after discovering alerts were triggering for "substitution attacks" without checking if packages came from private registries. Their own admission:

"Dependabot doesn't look at project configuration to determine if packages are coming from a private registry, so it has been triggering an alert for packages with the same name from the public npm registry."

In May 2023, GitHub shipped an auto-dismissal feature to reduce false positives by up to 15%. Harry Marr, a Senior Director at GitHub, acknowledged:

"In ecosystems with lots of dependencies like npm, false positives can cascade through a project, burdening developers with needless noise."

Sentry, a major developer tool company, explicitly advises developers:

"Dependabot alerts and npm audits often give false positive security warnings for frontend tooling libraries."

The pattern is clear: tools without context generate noise, not signal.

My solution: Manual updates with discipline

When I disabled Dependabot, I didn't stop caring about security. I just stopped outsourcing it to a tool that doesn't understand my project.

Here's my process for managing dependencies in my active Laravel project:

Regular updates: I run composer update and npm update regularly, usually when I open the project to start working. This is a natural part of my workflow, not an interruption.
Minor updates: For minor version updates (e.g., 5.2 to 5.3), I update quickly without extensive testing. These are typically bug fixes and small improvements.
Major updates: For major version updates (e.g., 5.3 to 6.0), I update and immediately run my test suite to ensure nothing is broken. If tests pass, I deploy.
Review changelogs: Before major updates, I scan the changelog for breaking changes that might affect my code.

This approach works better for me because:

I control when updates happen: Updates happen when I'm ready to deal with them, not when an email arrives in my inbox.
I review changes intentionally: I'm not reacting to an automated alert. I'm making a deliberate decision to update a package.
My test suite is my safety net: Every major update goes through my test suite before reaching production. If something breaks, I catch it.
No alert fatigue: I don't receive dozens of false positive alerts. When I do see a vulnerability (from reading release notes, security blogs, or composer audit), I pay attention.

This isn't "ignoring security"; it's taking responsibility for it.

Nuance: When Dependabot can be useful

I'm not saying Dependabot is universally bad. It has a place. It just doesn't have a place in my active Laravel project with disciplined manual updates.

Here's when Dependabot makes sense:

Inactive or maintenance-mode projects: If a project isn't actively developed, automated dependency updates can keep it from accumulating security debt.
Node.js projects with complex dependency trees: Node.js projects often have hundreds (or thousands) of transitive dependencies. Manual management becomes impractical, and the ecosystem is a common target for attackers.
Teams with dedicated security review: Large organizations with security teams can triage Dependabot alerts, filter out false positives, and focus on real threats.
Compliance requirements: Some organizations require automated security tooling for regulatory or policy reasons.

The key difference: my Laravel project is actively developed, and I have the discipline to update regularly. My context differs from Dependabot's default assumptions.

Dependabot is designed as a one-size-fits-all solution. But security isn't one-size-fits-all.

Conclusion: Trust your context

It's okay to disable security defaults. It's okay to say "this tool doesn't work for my project."

Security tools are helpful when they provide signal. They're harmful when they create noise. Dependabot, in my context, creates noise. It wasted my time investigating vulnerabilities that didn't affect my production application. It trained me to ignore alerts, which is dangerous when real threats emerge.

I'm more secure without Dependabot because:

I review every update intentionally: No more automated PRs I merge without thinking.
I test every major update: My test suite catches breaking changes before they reach production.
I pay attention to real threats: Without alert fatigue, I can actually notice and respond to vulnerabilities that matter.
I understand my dependencies: Because I update manually, I know what each package does and how it's used in my application.

Security isn't about having the most tools; it's about understanding your actual risks and addressing them deliberately.

Automated tools are a proxy for understanding. When the proxy lacks context, it's better to build understanding yourself.

My Laravel project is better off with manual updates, discipline, and trust in my own judgment than with Dependabot's noise.

Resources

npm audit: Broken by Design by Dan Abramov
Dependabot relieves alert fatigue from npm devDependencies - GitHub Blog
Dependabot alerts paused for malware advisories - GitHub Changelog
GitHub Dependabot alert: nth-check vulnerability - Sentry