Every confirmed finding ships with the evidence behind it. This guide walks through what each finding includes so you know what to read first and what to forward to engineering.

What a finding includes#

• Captured exchange — the HTTP request and response that demonstrate the issue, as raw HTTP you can replay from any standard client.
• Reproducible command — for Critical and High findings, a command that reproduces the exploit, plus a response hash you can re-check.
• Sandbox output — for findings reproduced in the sandbox, the captured output (for example, the result of id or hostname on an RCE finding) with customer data redacted.
• Impact and remediation — the impact statement, the relevant compliance mappings, and a remediation hint.

Sandbox output#

For a remote-code-execution finding, the captured output is the first place to look — if the exploit produced id, uname -a, or a canary string, the output shows it verbatim, with sensitive values redacted.

$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$ cat /etc/hostname
app-staging-7f3b

Captured exchanges#

Each step of a finding (or a chain) includes the request Pentrova sent and the response it received, as raw HTTP — method line, headers, body — so you can replay it directly. Chain steps are ordered so the path reads top to bottom.

Re-checking after a fix#

Re-run the reproducible command against the patched build. If the finding no longer reproduces, the fix worked. This is why every finding ships replayable: confirming a fix never requires Pentrova’s tooling.

What to forward first#

For most triage conversations, forward the captured exchange for the terminal step plus the impact statement. That is the minimum an engineer needs to understand the impact and start a fix; the rest is there when someone asks for more detail.