At a recent engagement with a financial-services client, we reviewed their GitHub Advanced Security findings and counted the open alerts. Over 2,000 of them. So we asked the obvious question: how many have you actually triaged? Less than 10%. We figured the highs and criticals had to be in better shape, since those are the ones that get someone paged at 2am. That rate climbed all the way to ~15% 🫠.
Sit with that for a second. Over eight out of every ten of their most severe security alerts had never been looked at by a human. Not fixed, not risk-accepted, not even opened and dismissed. Just sitting there, glowing red on a dashboard nobody trusts.
Here's the thing: this isn't a story about one customer falling behind. It's the steady state at almost every security program I've seen, and I don't think it's a discipline problem. The developers aren't lazy and the security team isn't asleep. The relationship between them broke, quietly, over years. And it broke for a reason almost nobody names out loud: false positives.
This is not new. Back in 2015, before "shift left" was even a slogan and before half the scanners on the market today existed, Ponemon found the average organization was already fielding 16,937 security alerts a week, judging just 19% of them reliable and actually investigating only 4%. They put the annual cost of chasing bad alerts at roughly $1.3M per organization. That was over a decade ago. The flood was already here; we just kept adding tools to it.
And the tools made it worse, not better. In Snyk's 2023 survey, 62% of teams said at least a quarter of their alerts were false positives, and 61% said automation had actually increased their false positives. Datadog's own telemetry tells the same story from the other side: of the tens of millions of malicious-looking requests their scanners flagged in 2024, 0.0065% actually triggered a vulnerability. We've built an industry that's astonishingly good at generating noise and astonishingly bad at telling you which signal matters.
Every one of those false positives is a small withdrawal from the same account: the developer's trust in the security team. The first time a tool files a finding against your code and you burn an afternoon proving it's a non-issue, you're annoyed. By the fifth time, you stop reading them closely. By the tenth, security has become the “boy that cries wolf”, and ignoring them becomes the rational move. GitLab's research on the developer-security divide put excessive false positives near the top of the friction list for a reason.
You can see where that ends. By 2025, Checkmarx found eight in ten companies were knowingly shipping code they knew was vulnerable, up from about two-thirds a year earlier. Their framing was blunt: "This isn't oversight. It's strategy." When the alerts can't be trusted, "ship it and sort it later" becomes the only sane way to keep moving, and "later" turns into Veracode's finding that 42% of applications now carry security debt over a year old. The backlog isn't a backlog anymore. It's a graveyard.
So that's the chasm. Decades of false positives taught developers that security findings are guilty until proven innocent, and that proving it is their job, not the tool's. That's the trust that has been eroded over the years, and that we have to win back.
This is the problem Nullify was built to solve, and we solve it by refusing to send you the noise in the first place. Every finding that reaches a developer has already been validated as a true positive. Our triage does the work of separating real vulnerabilities from the 80% that was never going to matter, so your team never sees it. And when something is real, we open the fix as a pull request, ready for review. We don't ask developers to be the last line of triage. We do that work before the alert ever lands.
If you saw the rates of FPs that we triage out, you would be astonished. One of our recent engagements, just with a limited deployment to ten repositories, showed 547 false positives compared to 105 true positives - and that’s on the low end compared to others.
The bet underneath the platform is simple: when every alert a developer sees is real, triage becomes worth doing again. Security stops being the team that cries wolf and goes back to being the team that caught something real. That's the bridge back. Not better dashboards or louder alerts, just the one thing AppSec quietly stopped delivering a long time ago: findings a developer can trust.
Written by: Bryan Taylor
Sources used: Ponemon/Damballa 2015, Snyk 2023, Datadog 2024, GitLab divide 2020, Checkmarx 2025, Veracode 2024.