I Got a Dependabot Alert. Here's Everything Wrong With How We Handle Security in 2026.
A high-severity CVE landed in my inbox while I was writing code. The alert told me I "might be affected." It didn't tell me what to do about it. This is the state of the art — and it's not good enough.
📬 The Email That Started This
Tuesday morning. I'm mid-flow, writing code. An email arrives from GitHub:
⚠️ A high severity security vulnerability has been found in axios (npm).
You might be impacted.
View all Dependabot alerts →
Axios. One of the most common packages in the JavaScript ecosystem. Millions of installs per week. And now it has a high-severity CVE.
The Five Questions This Alert Doesn't Answer
I stared at this alert and realised it fails at every level that actually matters for a developer trying to do the right thing. Here are the five questions I immediately had — and the five answers I didn't get.
What am I supposed to do?
The alert says "you might be impacted." Might. It doesn't say which version I'm running, whether the vulnerable code path is actually reachable in my application, or what the fix is. It just says "view all alerts" and sends me on a scavenger hunt through the GitHub UI.
A developer who gets this alert has to: open GitHub, find the alert, read the CVE, check their package-lock.json, determine if the vulnerable function is called anywhere in their codebase, find the safe version, update, test, and deploy. That's 30–60 minutes of context-switching for one alert. Most developers get dozens per week.
Who gets this alert?
It went to the repo owner. Not the developer who added the dependency. Not the team lead responsible for that service. Not the security engineer who should be triaging CVEs. The repo owner — who might be a founder, a PM, or someone who hasn't touched the code in months.
The person who can actually fix this — the developer who wrote import axios from 'axios' — has no idea this alert exists. They'll find out in a sprint planning meeting, if they're lucky. Or in a penetration test report, if they're not.
What's the actual risk to my application?
"High severity" according to whom? The CVSS score is a generic rating. It doesn't account for my specific usage. Maybe I only use axios for internal API calls behind a VPN. Maybe I use it to fetch user-supplied URLs from the public internet. The risk profile is completely different, but the alert is identical.
Without reachability analysis, every alert is Schrödinger's vulnerability — simultaneously critical and irrelevant until someone spends time investigating. Most teams don't have that time, so they either ignore alerts (dangerous) or treat everything as critical (unsustainable).
How long was I vulnerable?
The dependency was added weeks ago. Maybe months. The vulnerability might have been known in security circles before the CVE was published. The code has been in production, serving users, processing data, the entire time. The alert arrived after the damage window was already open.
IBM's 2025 Cost of a Data Breach report puts the average time to identify a breach at 276 days. Dependabot is faster than that, but it's still reactive. It's a smoke alarm that goes off after the fire's been burning for weeks.
What about the code the AI wrote around this dependency?
Here's the one Dependabot will never catch. The developer didn't just type npm install axios. They asked an AI assistant to build an API client. The AI chose axios, wrote the HTTP calls, handled the responses — and probably introduced its own vulnerabilities in the process: missing input validation, hardcoded timeouts, no retry logic, maybe even a Server-Side Request Forgery (SSRF) if it's passing user input directly to the URL parameter.
Dependabot scans dependencies. It doesn't scan the code that uses those dependencies. It doesn't know that an AI assistant wrote that code. It doesn't know that 45% of AI-generated code fails security tests. It's checking the lock on the front door while the windows are wide open.
This Isn't a Dependabot Problem. It's an Architecture Problem.
To be clear: Dependabot is a good tool. It does exactly what it was designed to do — scan dependency manifests against a CVE database and raise alerts. The problem is that we've been treating dependency scanning as if it's security, when it's actually just one narrow slice of it.
The security model most teams rely on looks like this:
The "Shift Left" That Didn't Actually Shift
The vulnerability enters the codebase at "Write code." The first detection happens at "CI/CD" or later. Everything in between is a blind spot.
This architecture made sense in 2020, when developers wrote code manually and the main risk was known CVEs in third-party packages. It doesn't make sense in 2026, when:
AI assistants don't just use dependencies — they choose them, sometimes hallucinating packages that don't even exist. They write code with known vulnerability patterns. They can be hijacked via prompt injection to produce backdoored code that looks perfectly legitimate. None of this shows up in a Dependabot alert.
What Should Actually Happen
The developer who added that axios dependency should have known about the risk at the moment they wrote the code — not weeks later via an email to someone else. Here's what that looks like:
Detection at the Point of Creation
The vulnerability never leaves the developer's machine. The right person sees it at the right time with actionable context.
This isn't a hypothetical architecture. This is how edge-first security tools work — scanning code locally, in the IDE, at the speed of a keystroke. No cloud round-trip. No waiting for CI. No email to the wrong person three weeks later.
The key differences:
| Reactive (Dependabot-style) | Real-time (Edge-first) | |
|---|---|---|
| When | Days to weeks after code is written | At file save (<50ms) |
| Who sees it | Repo owner (often not the author) | The developer who wrote the code |
| What's scanned | Dependency manifests only | Code patterns + dependencies + AI config files |
| AI-generated code | Not scanned | Scanned at generation time |
| Slopsquatting | Not detected | Hallucinated packages flagged |
| Rules file attacks | Not detected | Invisible Unicode & BIDI scanned |
| Data leaves machine | Code sent to cloud for analysis | Never. All local. |
The Real Cost of Reactive Security
Every Dependabot alert that arrives in production represents a chain of failures:
The Bottom Line
Dependabot isn't broken. It's just not enough anymore. The threat model has changed. Developers are writing code with AI assistants that choose dependencies, generate vulnerable patterns, and can be hijacked via prompt injection — and the security tooling most teams rely on was designed for a world where humans typed every line.
The fix isn't more alerts. It's earlier detection, by the right person, with actionable context. That means scanning at the point of creation — in the IDE, at file save, before the code ever reaches a repo.
That's what we built CodeMarine Guardian to do. But regardless of which tool you use, the principle is the same: if your security scanning starts at CI/CD, you've already lost the most important battle.
Related Research
Stop getting alerts about code that's already in production
CodeMarine Guardian catches vulnerabilities at file save — before they reach your repo. Free 14-day trial.