Why Most Dependency Alerts Don’t Matter

How Kilo Security Agent uses AI reachability analysis to reduce false positives and prioritize exploitable vulnerabilities

Last month I heard about an engineer on our team spending forty-five minutes investigating a critical Dependabot alert for a lodash command injection vulnerability. He traced the call paths, read the advisory, and checked our imports. The function wasn’t reachable. Forty-five minutes gone for a single alert out of hundreds. (This engineer may or may not have been me.)

This is common across teams using dependency scanners. If you’ve worked at a company that takes security seriously — or one that’s simply turned on Dependabot — the workflow is familiar: you open your alerts tab and see severity badges stacked across dozens of findings. Most probably don’t matter, but you don’t know which ones. So you either investigate them all or you start ignoring them. Neither option is good.

The scale of the noise

Endor Labs’ 2024 Dependency Management Report found that fewer than 9.5% of dependency vulnerabilities are reachable, meaning the vulnerable code path can be executed by your application. That’s over 90% noise. Coana’s research puts the false positive rate of conventional SCA tools at up to 95%.

In practice, your average codebase pulls in hundreds of dependencies, both direct and transitive. GitHub can tell you CVE-2024-XXXXX exists in version 4.17.20 of lodash. The missing context is whether your code ever touches the affected function. The alert is accurate as dependency metadata, but insufficient for prioritization.

The security industry has a name for this problem: alert fatigue. It is more than an annoyance. When developers learn that most alerts are irrelevant, they stop treating any of them as urgent. Reachable issues become harder to identify and prioritize.

What reachability analysis means

The concept is straightforward: before flagging a vulnerability as actionable, check whether your code can reach the vulnerable function. The useful question is whether your application has a call path to the specific code that’s vulnerable, rather than only whether the package appears in the lockfile.

This is what distinguishes useful security tooling from a package-version match against vulnerability databases.

Snyk, Endor Labs, and others have built reachability into their products. It works. But it typically requires you to adopt their entire platform, migrate your workflow, and pay enterprise pricing for what is often a filter on data GitHub already gives you for free.

Kilo Security Agent

We built Kilo Security Agent because we were drowning in alerts ourselves. We’re going through SOC2 and needed a real vulnerability management workflow: not just evidence that we had Dependabot turned on, but evidence that we were triaging and remediating findings in a timely, defensible way.

Security Agent syncs your Dependabot alerts across connected repos, then uses AI-powered static analysis to determine whether each vulnerability is exploitable in your codebase. The analysis is specific to each repository. A CVE in lodash’s command injection path doesn’t matter if you never call lodash.template with untrusted input.

How it works

The analysis follows a transparent four-step process for every finding:

1. Found package — identifies the vulnerable dependency and version in your lockfile

2. Reviewed advisory — reads the CVE details, affected functions, and exploit conditions

3. Checked repo usage — scans your codebase for imports and call paths to the vulnerable code

4. Determined reachability — concludes whether the vulnerability can be triggered

You see all four steps. If the agent says “no reachable risk found,” you can read why it reached that conclusion. We saw this with a lodash command injection finding: the agent traced our usage, confirmed we never invoke the affected function with user input, and classified it as safe to dismiss with the reasoning visible.

For findings that are reachable, the agent can also open a remediation PR. We watched it identify a handlebars prototype pollution vulnerability, confirm the reachable path, and open PR #5 with the version bump and test updates. No human intervention was required for a straightforward version upgrade.

Capabilities

• Audit reports with full severity breakdowns, exportable for compliance evidence

• SLA compliance tracking — configure per-severity deadlines, such as critical within 7 days or high within 30, with email notifications when findings go overdue

• Codebase risk analysis — a dashboard view showing where your repository risk lives

• Configurable automation — set thresholds for auto-analysis, auto-dismissal, and auto-remediation by severity and confidence level

What we learned from internal use

We’ve been running Security Agent against Kilo’s own repos as part of our SOC2 audit process. A few things stood out:

Most alerts were not reachable in our repositories. This was roughly in line with the industry data. The vast majority of our Dependabot findings turned out to be unreachable. We’d been spending engineering time on them anyway, because you can’t assume they’re irrelevant until you check.

Transparent reasoning changes behavior. When a tool says “dismissed — not reachable,” there’s an instinct to distrust it. When it shows you the four-step chain of reasoning — “found package X → reviewed advisory → checked your usage → no call path exists” — you can verify it in seconds. That makes review faster and easier to trust.

Auto-remediation needs guardrails. We don’t auto-merge PRs for everything. The confidence thresholds exist for a reason. You configure what severity levels and confidence scores warrant automatic action versus human review. For our SOC2 process, we auto-remediate low and medium findings with high confidence, and flag everything else for manual review.

Limitations

Current limitations:

• Dependabot only. Security Agent works with GitHub’s native Dependabot alerts. If you’re using Snyk, Renovate, or something else as your primary scanner, this won’t ingest those findings. Dependabot is the starting point; more sources will come.

• Requires Kilo Code credits. The AI analysis and remediation use model inference. You control how aggressively it runs via the automation thresholds, so costs are predictable, but it’s not free-tier functionality.

• Not a replacement for security review. This is triage and remediation automation. It doesn’t find new vulnerabilities in your first-party code. It manages the flood of known-CVE alerts in your dependencies.

Availability

Security Agent is available now for all Kilo Cloud users. Connect your GitHub repos via the KiloConnect GitHub App, enable Dependabot alerts on your target repositories, and configure your automation thresholds in Settings.

Teams and Enterprise plans include SLA enforcement, audit export, and priority support for compliance workflows. The docs cover the full setup.

The cost of ignoring this

Every engineering team I’ve talked to has the same story: they turned on Dependabot, got overwhelmed, and now either have someone spending hours each week on triage or, more commonly, a growing pile of unacknowledged alerts.

That backlog creates technical, legal, and regulatory risk. SOC2 auditors want to see evidence of timely remediation. Customers running security questionnaires want to know your SLA for critical vulnerabilities. “We have Dependabot turned on” isn’t an answer to “how do you prioritize and remediate known vulnerabilities?”

The industry data says over 90% of those alerts are noise. The reachable subset is where the highest practical risk usually sits. Automated reachability analysis can reduce the manual triage burden while preserving reviewable evidence.

We built Security Agent for our own SOC2 workflow, and it is now available to Kilo Cloud users.