The Findings queue includes several kinds of evidence. A source pattern, an advisory for a package version, and a maintainability observation do not establish an executed exploit. Source verification and sandbox proof are separate steps with their own recorded results.
The states a finding moves through
| State | What it means |
|---|---|
CANDIDATE | Suspected behavior awaiting further checks. Treat it as unverified. |
VALIDATING | Being checked right now. |
CONFIRMED | Source verification is recorded. This does not establish that an executed patch replay passed. |
LIKELY | Scanner evidence needs independent review before treating the finding as confirmed. |
UNCONFIRMED | Recorded verification could not reproduce the reported behavior. The result may remain visible for review. |
DISMISSED | Ruled out, either by validation or by you. |
FIXED | A later scan of a newer commit no longer reproduces it. |
Reachability
For a code finding, the question validation answers is whether untrusted input can actually get from where it enters to the dangerous operation. That is what the data flow on the finding records: the source, the sink, and every step between them.
Not every source is equally dangerous, and confidence reflects that. A flow starting at an HTTP query parameter, body, header, cookie, path parameter, webhook payload, or file upload is something a remote attacker controls directly. A flow starting at an environment variable or a database value is a real concern, but it is not remotely triggerable on its own, and it is not scored as though it were.
Guards that do not count
A guard only clears a flow when it genuinely defends the operation at the end of it. Parameterising a query defends a SQL execution. Escaping for HTML defends template rendering and HTML output. Neither of them defends a shell command, and neither is allowed to clear a flow into one.
Where a finding names ineffective sanitizers, that is what it is telling you: the code does call something protective looking on that path, and it does not protect against this. That is worth reading closely, because it is usually the reason the finding surprised you.
The confidence number
Where a confidence value is recorded, it ranges from 0 to 1. It is a check-specific estimate to read with the recorded evidence and verification state, not a guarantee of exploitability. Severity describes possible consequence; confidence describes the strength of support for the report. See Severity and confidence.
Reading it yourself
cf reproduced show <finding-id>The detail view carries the vulnerable code, the source and sink, every step of the path with its file and line, any ineffective sanitizers, and the research that matched. It is the evidence. The list is only a summary of it.
Have a correction or need help?
Email the docs team