Pentrova decides whether a candidate finding becomes a published finding by verifying it against the live target. The goal is simple: a finding only reaches your queue when there is evidence it is real.
What verification produces#
For every published finding you get the evidence behind the decision:
- The HTTP exchange that demonstrates the issue — request headers, body, response headers, and the relevant response excerpt.
- For Critical and High findings, a sealed-sandbox proof-of-concept that reproduces the exploit, with a captured command and a response hash engineering can re-check.
- For blind classes (blind , blind , blind ), the out-of-band callback that proves the target reached out — the callback receipt is the proof.
Findings you can re-check yourself#
Every finding ships with a reproducible command and the captured exchange, so your engineers can replay it in staging and see the same behaviour before touching the codebase. The point of verification is that the “is this a real bug?” conversation is already settled by the time the finding lands.
Passive observations#
Configuration findings — missing security headers, weak TLS, insecure cookies — are direct observations of the response and are reported as-is, with the evidence attached.