Cut false positives in AI assisted code scanning by requiring each finding to show a source, a sink and a path, filtering by reachability, tuning rules one at a time, and measuring precision over a labelled sample. Keep a human review for anything that blocks a merge.
Why do false positives happen?
Static analysis cannot see runtime context, so it flags patterns that are safe in practice. AI models add a second cause: they can describe a plausible flaw that is not there, or miss the sanitizer three files away. Both produce findings that waste an engineer's time.
The cost is not just wasted minutes. Once developers learn that most findings are wrong, they stop reading the right ones.
What cuts the noise?
Require evidence. A finding should name the untrusted source, the dangerous sink and the path between them. A vague "possible injection" without a path is a hint, not a finding. If an AI model proposes a finding, require it to point to the lines.
Check reachability. Reachability analysis asks whether the vulnerable code can actually be called from your application. For dependency findings, this removes flaws in functions you never use. For your own code, it removes issues in dead or test-only paths.
Understand sanitizers. Many false positives come from validation or encoding the tool did not recognise. Teach the tool your framework's safe functions, and your own wrappers.
Tune per rule. Do not turn off a whole category. Take the noisiest rule, review twenty findings, and decide: fix the rule, add a suppression pattern or retire it.
Scope by path. Treat tests, generated code and examples differently from production code.
Use a second opinion. A cheaper rule based pass finds candidates, and a model confirms or rejects with reasoning. This can help, but verify the model on your own labelled sample, because it can also confirm wrong ones.
Suppress with expiry. Record who suppressed a finding, why and when it expires. A suppression with no reason becomes a blind spot.
How do you measure progress?
Label a sample of recent findings as true or false, then calculate precision: true findings divided by all findings. Track it per rule and per language. Also track recall on a few known bugs you plant in a test repository, since cutting noise must not hide real flaws.
Watch the trend, not a single number. A precision of 40 percent that rises each month is a better sign than a flat 70.
What about AI generated code?
Code written by an assistant gets scanned like any other. Add checks at the editor and in the pull request, so the author gets feedback while the context is fresh. Do not trust the assistant to review its own output.
Our IDE extensions, CLI and reachability analysis are options for this workflow; the same principles apply to any scanner.
See the full walkthrough at /demos/exploitability-check.
What to do
- Label fifty recent findings as true or false and compute precision per rule.
- Require source, sink and path in every finding.
- Add reachability filtering for dependency and code findings.
- Tune the three noisiest rules, one at a time.
- Treat tests and generated code separately.
- Plant a few known bugs to check recall after each change.
- Record every suppression with a reason and expiry.
Quick check
Can an AI model eliminate false positives?
No. It can filter some, but it can also confirm wrong ones. Measure it on your own labelled findings.
Is turning off a noisy rule acceptable?
Sometimes, if you record why and check recall. It is better to tune the rule first, since disabling hides real issues too.
Sources
Last reviewed: 18 October 2026.
