A finding is not a finding until it reproduces. That is the rule Pentrova’s verifier enforces, and it is the reason the platform bundles evidence instead of severity scores. This post walks through the three stages the verifier runs before a candidate exploit graduates into a replayable proof-of-concept artifact — and why each stage exists.
If you want the design philosophy behind keeping the verifier small, read the verifier design notes; this post is the mechanics.
Stage one: clean-session replay#
Every candidate finding arrives with the exact request that produced it — headers, cookies, body, upload chunks, everything. Stage one spins up a fresh HTTP session with no inherited state, submits that request, and captures the response byte-for-byte.
The fresh session is the point. A finding that only reproduces with the original session’s cookies, cached tokens, or warmed state is not reliably exploitable — it is an artifact of that session. If the clean-session response differs from the original exploit response beyond an ignorable set of fields (timestamps, trace IDs, server-generated nonces), the finding is demoted out of the publish queue.
Stage two: byte-level comparison#
The clean-session response is compared to the original exploit response using a normalisation pass that strips well-known entropy sources. What matters is whether the markers of exploit success survive the replay:
- the leaked bytes that defined a BOLA finding,
- the authorisation state that defined a privilege bypass,
- the diff that defined the finding in the first place.
Pentrova publishes a candidate when the markers match and drops it when they do not. This is the same evidence-over-probability discipline described in deterministic proof over probabilistic CVSS — the marker either survives or it does not, and there is no “probably” branch.
Stage three: bundle and hash#
The verified finding is packaged into a bundle containing the request, both response captures, the verifier trace, and — where applicable — a sandbox command log from the sealed sandbox. The bundle is hashed with SHA-256, and the hash is recorded both inside the bundle and on the finding record in the platform.
bundle = { request, clean_response, original_response, verifier_trace, sandbox_log? }
bundle_hash = SHA-256(bundle)
# recorded on the finding record AND inside the bundle
Anyone who later receives the bundle can recompute the SHA-256 over the bundle contents and compare it against the recorded hash. Matching hashes mean the bundle has not been altered since the verifier produced it. (To be precise: this is an integrity hash for tamper-evidence, not a cryptographic signature.)
Why this discipline matters#
The triage tax on most security tooling is the cost of sorting real issues from false positives. The verifier reduces that tax to near zero by refusing to publish a finding until the exploit reproduces in a clean session. The bundle is the proof; the recorded hash confirms it has not been altered. That is what makes a finding gateable in CI and replayable by an engineer against a fix branch.
Key takeaways#
- Stage one replays the exploit in a clean, stateless session — session-dependent artifacts are demoted.
- Stage two diffs responses with entropy normalisation; the finding publishes only if success markers survive.
- Stage three bundles the evidence and records a SHA-256 integrity hash for tamper-evidence.
- The net effect is a near-zero false-positive queue that engineers and CI gates can trust.
FAQ#
Why replay in a clean session instead of reusing the original? Because a finding that only reproduces with the original session’s warmed state is not reliably exploitable. A stateless replay proves the exploit works from scratch, which is the only result worth shipping.
What does the SHA-256 hash guarantee? Integrity. Recomputing the hash over the bundle and matching it against the recorded value confirms the evidence has not been altered since the verifier produced it. It is tamper-evidence, not a signature.
What happens to a candidate that does not reproduce? It is dropped before it reaches your queue. No reproduction, no finding — that is the rule the verifier exists to enforce.
Read the verifier design notes for the philosophy, or see the platform pipeline.