A quarter of CVEs on our own repos

Everyone is quoting "+30% CVEs in 2026" right now, and I have repeated it too. But my gut said it was worse on the ground. Teams run the same frameworks and packages across dozens of apps and repos, so every new CVE hits the same codebase in many places. The industry count tells you how many new vulnerabilities showed up. It does not tell you how many alerts a security team actually has to deal with.

So I pulled our own data from GitHub Advanced Security.

The view from our own repos

Across every Konvu repo, Dependabot opened 44 CVE alerts in Q4 2025 and 182 in Q1 2026. That is a +314% jump in a single quarter.

The severity mix shifted the same way the totals did:

Every ecosystem grew but npm grew the most:

npm also had the worst severity mix: 80 of its 123 Q1 alerts were high or critical (65%), against 48% for pip and 27% for Go. If you ship a JavaScript stack you already feel this.

Our repos are small compared to our customers' repositories. But the trend lines match what we see on their side at much larger scale. The gap between "+30%" and what lands in a team's backlog is about stack duplication. One CVE in a popular transitive package like minimatch can sit inside dozens of dependency trees across your services. A "modest" uptick in public CVE counts turns into a step change in ticket volume.

Of 182 alerts, 3 were actually exploitable

We ran our exploitability analysis on every Q1 alert. 3 out of 182 were exploitable in the context they were flagged, so that's just under 2%.

A few weeks ago we published a post on what happens when you enable Dependabot on a fresh fork of Metabase: 53 findings and zero exploitable. It's exactly the same pattern. A scanner's job is to flag anything that might matter, and it does that well. The work left behind is deciding which of those findings actually matter in your code, your config, your deployment.

At Konvu we care about security, and these past months we have started feeling what our customers feel at much smaller scale. We are a team of 15. Some of our customers are 100x the size, with the same dynamic at 100x the volume. The math does not work. We run Konvu on Konvu, and we are very glad we do :)

Stop chasing every CVE and focus on the 2%

Focusing on the 2% only works if something is doing the analysis for you. That is where Konvu fits. We sit behind the scanners you already run. For every alert, we walk each dependency tree the vulnerable package sits in, and every call path inside that tree from your code down to the vulnerable function. Along the way we check: is the function actually reached in your code? Can attacker-controlled input make it there? Are the exploit preconditions met in the way your service is deployed? That is the work teams cannot do by hand at 182 alerts a quarter, let alone tens of thousands. If the answer is no on every path, the alert is closed with a written verdict and the evidence trail. If there is a real path, the right person gets pinged with a safe-to-merge PR.

Instead of dumping tens of thousands of CVE alerts over the fence to developers, teams get the hundred or so that are real, with most of the rest auto-resolved and documented. The reachability vs exploitability post goes into the distinction and why both layers matter.

April is already past all of Q4

One last data point. As of April 21, 2026, we have logged 70 CVE alerts in April alone. Twenty-one days into the month, we are already past the 44 alerts from all of Q4 2025.

Takeaway

Scanners are flagging everything they should, and then some. The gap is what you do with what you find, and that gap is widening fast. A +30% industry number becomes +314% in a single team's queue, and the real signal is hiding in the 2% that are actually exploitable.

If your AppSec team is spending its week closing "vulnerabilities" tickets by hand, we should talk.