To triage a DAST report, group findings by weakness type, reproduce each high severity item by hand, mark each as confirmed, false positive or needs more information, and tune the scanner so the next report is shorter. Never close a finding without writing down why.
What a finding contains
A good finding shows the request, the response evidence, the affected URL and parameter, a severity and a fix hint. A weak finding shows a rule name and nothing else. Prefer findings you can replay.
Triage categories
| Verdict | Meaning | Action |
|---|---|---|
| Confirmed | You reproduced the problem | Ticket with owner and due date |
| False positive | Evidence does not hold | Suppress for that URL, note reason |
| Accepted risk | Real but not worth fixing now | Record approver and review date |
| Needs info | Cannot decide | Manual test or ask the developer |
Steps
- Sort by severity, then group repeated findings by type, since one root cause often shows as many URLs.
- For each high item, replay the request with a command line client and read the response.
- Check whether the issue applies in production. Staging might have debug settings production lacks.
- Check whether the response is a custom error page that the scanner misread.
- Record the verdict and evidence in the ticket.
- Suppress confirmed false positives narrowly, by rule and URL, not globally.
- Rescan after fixes to confirm closure.
Signs of a false positive
The evidence text is generic. The response is the same for the payload and for a harmless value. The finding is on a static asset. Another finding with the same pattern is not reproducible. Remember that scanners have no way to judge logical flaws; ZAP's documentation notes that active scanning does not find things like broken access control, so a short report is not a clean bill.
Keep a suppression log
Store each suppression with a reason, an owner and a review date. Old suppressions hide new problems, so expire them.
Try it yourself
Open a finding in the demo and practice choosing a verdict.
Click through it at your own pace, or open it full screen.
Quick check
Should I trust a scanner's severity?
Treat it as a starting point. Adjust by exposure, data sensitivity and whether the issue is reproducible.
Is it fine to suppress a rule globally?
Only if it never applies to your app. Narrow suppressions are safer.
Where Safeguard fits
Safeguard offers dependency and SBOM scanning, reachability analysis and policies and gates that can block a pull request, so the libraries behind your app are checked alongside the app itself. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
