Triage SAST/DAST Findings and Cut the False-Positive Pile with AI

AI is well suited to the classification work in the middle: given a finding and the surrounding code, it can reason about whether the tainted path is actually reachable, explain why in terms a developer will accept, and cluster the pile so you triage patterns instead of individual lines. What it cannot do is decide, unaudited, that a finding is safe to close. This playbook keeps you in that loop.

When to reach for this

• •
  A SAST/DAST/dependency scan returned more findings than the team can review one by one.
• •
  You want consistent, explained triage decisions rather than gut calls that vary by reviewer.
• •
  Recurring false-positive patterns (a sanitizer the tool doesn't recognize, a framework guard) are drowning the real signal and you want them clustered and suppressed as a group.

The workflow

1. 1.

   Export findings as structured data so you can feed them back with context:

   Copy

   semgrep --config auto --sarif services/ > /tmp/findings.sarif
   

2. 2.

   For each finding, give the model the rule, the code, and the data-flow question. Ask for a reachability judgment with reasoning:

   Copy

   You are triaging a static-analysis finding in code I own. Decide whether
   it is a TRUE positive (exploitable), a FALSE positive, or NEEDS REVIEW.
   
   Base your decision on whether attacker-controlled input can actually
   reach the sink. State the exact data-flow path if true positive, or the
   specific reason it cannot be reached if false positive. If you cannot
   determine reachability from the code shown, say NEEDS REVIEW and name
   what additional code you'd need to see.
   
   RULE: <rule id + message>
   CODE (with surrounding context):
   <paste the function + callers>
   

   Expected output per finding: a verdict, a data-flow path or a reason-not-reachable, and — for anything it can't resolve — an explicit request for more context rather than a guess.

3. 3.

   Cluster the pile before you drill in. Ask the model to group findings by root cause:

   Copy

   Here are 140 findings. Group them by underlying cause (same sanitizer
   not recognized, same framework guard, same genuinely-vulnerable pattern).
   For each cluster: the shared cause, count, and whether the cluster as a
   whole is likely true or false positive.
   

   Triaging 8 clusters is tractable where 140 findings is not, and a whole cluster can often be suppressed with one rule tweak or confirmed with one code fix.

4. 4.

   Confirm true positives, then hand them to remediation. Route the survivors into the remediation-guidance and regression-test playbooks.

5. 5.

   Tune the rules for confirmed false-positive clusters. Where a cluster is noise because the scanner doesn't understand a real sanitizer, encode that — a Semgrep pattern-not or a CodeQL sanitizer definition — so the noise never returns.

Verify before you trust it

• Confirm every "false positive" by tracing the flow yourself. Pick the highest-risk dismissals and walk the input from source to sink. If the model claimed a sanitizer neutralizes the input, read the sanitizer — does it actually cover this input type, or only the common case?
• Confirm true positives are genuinely reachable before you escalate. A model can over-flag too. The exploit path it names should survive your own read; if you can't reach the sink with attacker-controlled data, downgrade.
• Re-run the scanner after rule tuning. Confirm the suppressed cluster is gone and — the important part — that your suppression didn't also hide a real finding that happened to match the pattern.
• Spot-check clusters, not just samples. Within a "false positive" cluster, one member may differ subtly and be real. Read each cluster's outliers.

Pitfalls

• Auto-closing on the model's say-so. The single most dangerous move here. A dismissal without a human data-flow trace is how a real bug gets a "reviewed, not exploitable" label and ships.
• Over-broad suppressions. A rule tweak that silences a false-positive cluster can silence real findings that share the pattern. Scope suppressions tightly and re-scan.
• Context starvation. The model can only judge reachability from the code you show it. If you paste a single line, expect NEEDS REVIEW or a confident wrong guess — give it the callers.
• Trusting the cluster label over the members. Clusters accelerate triage but hide outliers. The unusual member of a "safe" cluster is exactly where the real bug hides.
• Losing the audit trail. Record the model's reasoning and your confirmation for each dismissal — auditors and incident responders will ask why a finding was closed.

Tools

• SemgrepSARIF output and easily-authored pattern-not rules make it ideal for the export → triage → suppress-cluster loop.
• CodeQLprecise dataflow means its reachability verdicts are strong ground truth to check the model against, and its sanitizer model lets you encode confirmed false-positive causes.
• Snyk (or an OSS dependency scanner)for dependency and SCA findings, where AI triage helps separate reachable vulnerable calls from transitive noise.

Client-safe variant

Findings reports embed file paths, code, and sometimes secrets. Before prompting, redact real paths and any credential or customer identifier in the code context, and strip proprietary logic down to the security-relevant control flow. If the client bars external AI tools, run a local model for the classification prose — the scanners themselves (Semgrep, CodeQL, Trivy) run entirely offline and produce the SARIF you triage. Keep the audit trail of dismissals inside the client's own tracker, and get per-client approval before any finding leaves their boundary.