To cut false positives in application security posture management (ASPM), merge duplicate findings, check whether vulnerable code is reachable, rank by known exploitation, and require a written reason for every suppression. A good result is fewer findings an engineer must read, not fewer findings that exist.
Where does the noise come from?
Four sources produce most of it.
Duplicates. Several scanners report the same underlying issue, and the same flaw appears once per repository or image that includes it.
Unreachable code. A dependency has a flaw in a function your application never calls.
Wrong context. A finding in a test dependency, a build tool or a path that never ships.
Stale or mismatched matching. An advisory is matched to the wrong package version or ecosystem.
Each needs a different fix, so sample first. Take fifty findings and label why each is noise or real.
What actually reduces it?
Deduplicate by root cause. Group findings by the vulnerable component and fixing action. One upgrade that clears forty findings is one work item.
Add reachability. Check whether the vulnerable code path can be reached from your application. Reachability analysis is a method, not a guarantee, so keep the evidence visible and allow a human to override it. Used well, it cuts the list engineers must read.
Use exploitation signals. CISA maintains a Known Exploited Vulnerabilities catalog. A reachable flaw that is on that list should outrank a theoretical one. Scoring systems such as CVSS describe severity, and exploitation data describes likelihood. Use both.
Separate environments. Tag findings by whether the code ships to production, runs in a build, or exists only in tests. Treat them differently.
Fix the matching. If wrong version matches keep appearing, report them to the data source and add a reviewed override with an expiry date.
Govern suppressions. Each suppression needs a reason, an approver and a review date. This keeps noise reduction from turning into hidden risk.
What should you not do?
Do not lower every severity by one level to make the chart look better. Do not auto close findings after a fixed number of days, since old flaws are often still exploitable. Do not accept a vendor's claim that a finding is a false positive without seeing the evidence, and do not let one person suppress findings in their own repositories without a second reviewer. Each of these shortcuts trades visible noise for invisible risk, and invisible risk is the harder kind to find later.
How do I know it worked?
Measure at three points: the raw count of findings, the count after deduplication, and the count a person must act on. Track these over a few weeks. Also sample the suppressed set monthly and check that nothing real was buried. If the tool makes the dashboard greener by hiding findings that an engineer would have fixed, treat that as a failure.
Safeguard offers reachability analysis as part of its platform, and its CLI can run scans locally. Whatever tool you use, apply the same sampling test.
What to do
- Label fifty findings by cause of noise before changing anything.
- Turn on deduplication by component and fix action.
- Enable reachability analysis and review a sample of its decisions with an engineer.
- Rank reachable findings that appear in CISA's known exploited list first.
- Tag findings by environment: production, build, test.
- Require reason, approver and expiry for every suppression.
- Review the suppressed set monthly.
- Report three counts: raw, deduplicated, actionable.
Quick check
Is a reachability result always right?
No. Static analysis can miss dynamic calls and can also over report paths. Treat it as strong evidence you can check, and allow a human override with a note.
Should I ignore low severity findings?
Not by default. Low severity items can matter when combined or reachable. Rank them lower and revisit on a schedule.
Sources
Last reviewed: 18 October 2026.
