What is Verified Finding?
A definition, and how it applies in practice.
A verified finding is a reported vulnerability that has been confirmed to be real in the target environment through collected evidence, rather than inferred from a version number, a response header, or a signature match.
In depth
Understanding Verified Finding
Most security tooling reports possibility, not fact. A scanner sees a version string associated with a CVE and reports the CVE, without establishing that the vulnerable code path is reachable, the feature is enabled, or a mitigation is absent. Each such report is true as a statement about a version and often false as a statement about your system.
The cost lands on engineering. A queue of several hundred unverified findings requires triage before any of it can be acted on, that triage is skilled work, and the predictable result is a backlog nobody finishes — with the genuine finding sitting somewhere inside it.
Verification inverts the burden: the platform establishes exploitability before reporting, and ships the evidence that establishes it. The queue gets shorter because it is more accurate, not because it was filtered.
In RedStrike
How RedStrike handles Verified Finding
Verification is RedStrike's central claim. Findings are corroborated with collected evidence and de-duplicated across tools before they reach you — one issue seen by three scanners is one entry, not three — with severity normalized to CVSS and weighted by CISA KEV membership and EPSS probability. Verified findings are included on every plan including Free, because a free tier showing unverified noise would argue against the product.
See also
Related terms
FAQ
Frequently asked questions
Common questions about Verified Finding.
Why does RedStrike not claim zero false positives?
Because no honest vendor can. Verification means a finding is reported with evidence of exploitability rather than on inference, which removes the large class of version-match false positives — the ones where a version string implies a CVE that your build never reaches. What it does not remove is judgement: whether a confirmed weakness matters in your context is a question about your business, and that still needs a human.
Is a verified finding the same as an exploited system?
No. Verification is non-destructive: it establishes that a weakness is reachable and exploitable without causing damage, taking data, or leaving persistence. Confirming a door is unlocked is not the same as taking what is inside.
See Verified Finding in practice
Run continuous, verified security testing across your applications, APIs, and cloud accounts.