38 / 89 · 04 API & Contract Testing with AI · Fuzzing Implementation← prev⊞ allnext →☰ Read as one page
6.5Interpreting Results
False Positive Reduction
Not every anomaly is a real vulnerability. Common false positives:
| Anomaly | Often a False Positive When | Action |
|---|---|---|
| 500 error on type confusion | API returns 500 instead of 400 for bad types | File as code quality issue, not security |
| Slow response on large payload | API legitimately processes large data | Increase timeout threshold |
| XSS "reflection" in error message | Error message includes the input value | Check if HTML is escaped in the response |
Triage Workflow
1. Sort findings by severity (CRITICAL → HIGH → MEDIUM → LOW)
2. For each HIGH/CRITICAL:
- Reproduce manually with curl
- Verify it is not a false positive
- File a security bug if confirmed
3. For each MEDIUM:
- Reproduce, assess business impact
- File as bug or tech debt based on impact
4. For each LOW:
- Log for awareness
- Fix opportunistically (do not block releases)