Security teams don't have a scanning problem. They have a signal problem. A mid-sized engineering org running SAST, SCA, and container scanning across even 150 repositories can generate 3,000-8,000 open findings in a given month — and industry research consistently shows that 60-80% of them never warrant action. Analysts spend their week triaging noise instead of fixing exploitable issues, and eventually they stop looking closely at all. That's how a real vulnerability sits unpatched for months inside a pile of 40 "critical" alerts nobody trusts anymore.
Aikido Security has built part of its pitch around consolidating scanners into one dashboard to cut alert fatigue. Consolidation helps, but it doesn't solve the underlying accuracy problem — a wrong finding shown once in a unified view is still a wrong finding. This post breaks down where false positives actually come from, what they cost, how different vendors (including Aikido) try to reduce them, and what actually moves the needle.
Why Do Security Scanners Generate So Many False Positives?
Most false positives come from scanners matching on version strings instead of actual code behavior. A CVE gets published against lodash@4.17.15, and every SCA tool in the market flags every project pinning that version — even when the vulnerable function is never imported, never called, or was patched via a backport that didn't bump the semver. GitHub's own 2023 Octoverse data noted that over 90% of vulnerability alerts on Dependabot-enabled repos were never acted on, and third-party research (including a widely cited 2022 Endor Labs study) found that fewer than 1 in 10 flagged open-source vulnerabilities are actually reachable from application code. Static analysis tools have a parallel problem: pattern-matching rules for things like SQL injection or path traversal fire on sanitized input, framework-level protections, or dead code paths, because the scanner has no runtime or call-graph context. The tool isn't wrong that the pattern exists — it's wrong that the pattern is exploitable.
How Much Time Do False Positives Actually Cost Security Teams?
They cost hours per week per engineer, compounding into weeks of lost throughput per quarter. A 2023 survey from the Ponemon Institute found security teams spend an average of 25% of their time chasing alerts that turn out to be non-issues, and separate research from IDC put the average enterprise SOC at over 11,000 alerts per day across all tooling, with well under half ever reviewed. In supply chain security specifically, a single npm audit or pip-audit run on a moderately sized monorepo can return 200+ advisories after a routine dependency bump — and if even 15 minutes is spent per finding to confirm it's a non-issue, that's 50 hours of engineering time gone in a single sprint, spent on things that changed nothing. That's before counting the second-order cost: developers who get burned by three false positives in a row start ignoring the fourth alert, which might be real.
Does Reachability Analysis Reduce False Positives More Than Severity Scoring?
Yes — reachability analysis addresses the root cause, while severity scoring (CVSS, EPSS) only reprioritizes noise without removing it. CVSS tells you a vulnerability is theoretically severe; it says nothing about whether your application can ever reach the vulnerable function. EPSS improves on this by estimating real-world exploitation likelihood, and it's a meaningful step (CISA and several vendors adopted it through 2023-2024), but it's still a population-level probability, not a fact about your specific codebase. Reachability analysis — tracing whether a vulnerable function is actually imported, instantiated, and invoked from your application's entry points — is the difference between "this library has a flaw" and "this flaw is exploitable in your running system." In practice, teams that layer reachability on top of CVSS/EPSS report suppressing 70-90% of SCA findings as non-actionable without missing exploitable issues, because the analysis is deterministic about call paths rather than statistical about populations.
How Does Aikido Security Approach False Positive Reduction?
Aikido's approach centers on deduplication and consolidation: aggregating SAST, SCA, secrets, and cloud findings from multiple scanning engines into a single triage queue, then using autotriage rules and reachability checks (introduced for their SCA product) to suppress some low-value alerts. This is a real improvement over running five disconnected scanners and manually cross-referencing CVE IDs across five dashboards — that workflow alone can eat a day per week for a security engineer at a Series B company. But consolidation is an interface-layer fix. If the underlying scanning engines are still flagging unreachable code or misclassifying sanitized inputs, a unified dashboard just makes it faster to dismiss noise one click at a time instead of five. It reduces the friction of triage without necessarily reducing the volume of things that need triaging in the first place, and reachability coverage that's limited to one finding type (typically SCA) leaves SAST and IaC noise largely untouched.
What Role Does Contextual Risk Scoring Play in Triage?
Contextual risk scoring turns "is this exploitable in theory" into "does this matter for us, right now," by factoring in exposure, data sensitivity, and deployment status. A vulnerability in a library used only in an internal build script scores very differently than the same CVE in a package reachable from an internet-facing API that handles customer PII. Concretely: if a finding is in code that hasn't shipped to production, sits behind a network policy with no external ingress, or lives in a repository archived more than six months ago, it should never reach a human's queue at the same priority as an actively-exploited flaw in a payment-processing service. Gartner's 2023 guidance on vulnerability prioritization technology (VPT) explicitly called out asset context and business criticality as the two biggest gaps in scanners that rely on CVSS alone. Teams that add this layer typically see their "must fix this sprint" list shrink from hundreds of items to single digits, because context does the filtering that severity scores can't.
How Safeguard Helps
Safeguard was built around the premise that supply chain security tooling has to earn developer trust by being right more often, not just faster to dismiss. Where consolidation-first tools reduce the number of clicks per alert, Safeguard focuses on reducing the number of alerts that need a click at all.
Concretely, Safeguard applies reachability analysis across the full scanning surface — not just SCA, but SAST and IaC findings too — tracing whether flagged code paths are actually invoked from real application entry points before a finding ever reaches a queue. Findings are enriched with deployment and exposure context automatically: whether the affected service is internet-facing, whether it processes sensitive data classes, and whether the vulnerable code has shipped to production at all. That context is pulled from the same SBOM and dependency graph Safeguard already maintains for compliance and provenance tracking, so there's no separate integration step to wire up asset criticality.
Safeguard also tracks suppression decisions over time and feeds them back into the scanning pipeline, so a false positive dismissed once (say, a sanitized-input SQLi flag in a well-understood code path) doesn't reappear identically on the next scan of an unrelated branch. Teams using this workflow typically report clearing their actionable backlog in days rather than the weeks it takes when every scan starts from zero. For teams evaluating Aikido or any consolidation-first platform, the question worth asking isn't "how fast can I dismiss this alert" — it's "why did the scanner surface it in the first place." Safeguard is built to make that second question rare.