Scan Execution, Results Triage, and False Positive Management
What this domain tests
Your grasp of the scan lifecycle and of the result-state workflow that turns raw findings into a defensible audit trail. Most wrong answers here come from confusing scan states with result states, or from taking actions the role does not permit.
Scan lifecycle
A scan moves through queued, running, finished, failed, or canceled. Results are available only for finished scans, and a failed scan usually points to source access, engine connectivity, encoding, or a configuration problem - not to a code issue.
Result states
Each result carries a state that records a human judgement:
- To Verify - the default for new results; nobody has assessed it.
- Confirmed - validated as a real issue.
- Proposed Not Exploitable - proposed false positive, which requires a written reason.
- Fixed - resolved; normally set after a rescan no longer reports it.
- Recurrent - previously fixed but reported again.
States are permissioned: a Scanner can run scans but not adjudicate results, while a Reviewer approves false positives and a Manager can bulk-apply decisions. Comments, assignment, and severity adjustments are captured in the audit trail and should justify every state change.
Worked example
A result flags executeQuery on a query built entirely from string literals inside a constants class. Reasoning: trace the argument back - no request, header, file, or argument feeds it, so no source reaches the sink; the query's source list simply does not include that data. Mark it Proposed Not Exploitable with the reason "static constant query; no external input reaches the sink" and route it to a Reviewer. Do not delete it, and do not mark it Fixed - the code has not changed.
A second result on user-controlled id should be Confirmed and assigned to the owning developer, with the source-to-sink path quoted in the comment.
Traps that cost marks
- Clicking Fixed without a rescan; the finding returns as Recurrent and corrupts trend data.
- Marking false positives without a reason, which blocks review and destroys the audit trail.
- Triaging while the scan is still running, then losing decisions on completion.
- Treating Not Exploitable as deletion; the result remains queryable in reports.
- Assuming any user can change states.