Dashboard Fatigue And Signal Collapse: Why Security Teams Can’t See What Matters Anymore

Abby Kearns is CEO of ActiveState, a veteran tech executive with 25+ years scaling enterprise software companies.

gettyA large bank’s security leader that I spoke with said their team was managing over 220,000 lines of dependency data, with the fixes owned by dozens of application teams moving at different speeds. Some of the flagged components can take more than a year to upgrade. Their tools made finding vulnerabilities far easier, but they didn’t make any of them faster to fix.

The result is dashboard fatigue, and it’s getting worse. Most security teams already run a stack of scanners, aggregation platforms and alerting tools, and AI-assisted discovery has been added on top of it. Visibility has grown faster than teams can keep up with, and they’re struggling to tell which findings carry real risk to the business.

As of early October 2026, Anthropic’s public dashboard showed “6,157 vulnerabilities across 591 open-source projects.” However, only 516 had been patched.​

Consider that every new finding depends on maintainers and contributors—often a small group—to confirm, fix and get a release out. Curl, one of the most widely deployed libraries in existence, shut down its bug bounty program in January 2026, citing the time its maintainers were losing to a flood of low-quality, often AI-generated submissions. For everyone downstream, the result is a growing list of known vulnerabilities in open-source code that have no upstream fix yet, and no amount of prioritization on your side changes when that fix arrives.

According to Black Duck’s 2026 “Open Source Security and Risk Analysis” report, 98% of codebases contain open-source software. So, the gap between findings and fixes reaches nearly every organization, and many don’t know how much open source they’re actually running. I expect this to settle as projects adapt their processes and AI starts helping with fixes, not just findings.​

The volume would be far easier to manage if teams could tell which alerts matter in their own environment. A severity score is a useful starting point, but it describes the vulnerability, not your exposure to it, and that’s before you get to how inconsistently scores are assigned.

Whether a finding is truly critical depends on whether the code is running in production, whether it can be reached from the internet and what data sits behind it. Datadog’s “State of DevSecOps 2026” report, drawn from telemetry across tens of thousands of applications, found that just 18% of vulnerabilities labeled critical stayed critical once runtime context was applied. Yet, 87% of organizations still had one or more exploitable vulnerability in production.​

On our own team, a critical-rated alert tied to Spring4Shell kept generating tickets for systems that had no real exposure to it, and someone still had to check each one manually. Without context on exposure, a dashboard ranks findings by how bad they look on paper rather than by what actually puts the business at risk.

1. Begin with an accurate inventory, or as close to accurate as you can get. It’s tedious work, but you can’t rank findings for systems you don’t know you have. That means creating a current list of environments and servers, on premises and in the cloud, and the software running on each, which is what a software bill of materials (SBOM) is for. Matching findings against that list lets your team set aside alerts for code it doesn’t run and move the ones touching production and customer-facing systems to the top.

2. Merge duplicate findings before anyone triages them. When the same vulnerability shows up in three tools with three different severity ratings, it should become one finding with one owner. Many teams try to fix this by consolidating tools, but that’s a project of its own, with time and budget most can’t commit right now. Consolidating findings is a decision a team can make quickly, and in my experience, it does more to shorten the list.

3. Every finding also needs a named owner, and this is where automation reaches its limit. When I was CTO at Puppet, our customers were running infrastructure automation at scale, and the recurring question was which changes could run on their own and which still needed a person to review them before they went out. We learned that this boundary is something that needs to be designed deliberately. Automation is very good at sorting and deduplicating findings, but a person still has to decide what happens next, and a finding without an owner tends to sit on the dashboard indefinitely.

4. The last step matters most because everything above helps a team keep pace with the backlog, and prevention is what makes it smaller. If many of the vulnerabilities now being disclosed in open source won’t have an upstream fix for some time, the part you control is what gets into your environment in the first place. For infrastructure, that means new servers and cloud accounts start from a hardened standard configuration. For open source, it means pulling packages from a vetted source, so known vulnerable code is caught before it reaches your applications.

Dashboard fatigue happens when visibility grows faster than the decisions behind it. The tools will keep getting better at finding problems, and the teams that keep up will have already decided which findings belong to them, who fixes each one and what they no longer let in.​​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?