Your CVE backlog is mostly noise. Here's the part that isn't.

Open your dependency scanner. Look at the number next to "Critical." If it has three digits, you already know where this is going, because I promise you no engineer on your team has read to the bottom of that list. They read to about item twelve, discovered that ten of them were in a transitive dependency of a build tool that never runs in production, and quietly stopped opening the emails.

That is the real cost of a noisy scanner. Not the noise itself — the fact that it trains your best people to ignore the one alert that mattered.

"You have it" is not "you can be hurt by it"

A CVE against a library means a flaw exists somewhere in that library's code. That is all it means. The version comparison your scanner does — you have 2.4.1, the fix is in 2.4.2 — is a statement about a version number. It says nothing about whether your application ever calls the vulnerable function, whether attacker-controlled data can reach it, or whether the path is even compiled into your build.

Most of the time, it cannot, it does not, and it is not. Study after study, and our own read of client codebases, lands in the same place: the large majority of flagged vulnerabilities are not reachable in the application that shipped them. They are real bugs in someone's library. They are just not your problem this week.

Reachability, briefly

Reachability analysis asks a different and much better question. Not "do you have the vulnerable version" but "is there a call path from something an attacker can influence to the vulnerable code?"

Concretely:

• The vulnerable function exists in the dependency. Fine.
• Does your code — or anything your code calls — actually invoke it? If nothing in your call graph reaches that function, the CVE is inert. File it, do not page anyone.
• If it is called, can input an attacker controls flow into the dangerous argument? A hash function with a weakness that only matters for attacker-chosen inputs is a non-event if the only thing you ever hash is a constant.

The version of a package tells you almost nothing. The call path tells you nearly everything. This is exactly the gap between a scanner and a reviewer — and it is the gap we built Hornet to close, because we were tired of triaging our own backlog by hand.

What to do on Monday

You do not need to buy anything to start. You need to change what you rank on.

1. Split the list by reachability, even crudely. Even a rough "is this package imported and called anywhere in our first-party code" cut will move most of your criticals into a "later" pile. Several open-source tools do a passable job of this per-language.
2. Rank the reachable set by exposure, not CVSS. A medium-severity bug on your public login path outranks a "critical" in an admin tool three people use over the VPN. CVSS does not know which of your endpoints faces the internet. You do.
3. Give engineers the call path, not the CVE id. "This function, called from this route, with user input from this parameter" is something a developer can fix before lunch. "CVE-2026-XXXXX, severity 9.8" is something they will forward to someone else.

The trust argument

There is a softer reason to do all this, and it might be the most important one. Security tooling only works if the people receiving its output believe it. Every unreachable "critical" you send an engineer is a small withdrawal from that account. Do it for long enough and the balance hits zero — and then the day you are genuinely on fire, your alert looks exactly like the ninety that were nothing.

Cut the noise not because the noise is expensive, but because the signal is priceless and you are burying it. Two confirmed, reachable issues that get fixed this week beats nine hundred that get ignored forever. It is not even close.