The short version. A vulnerability report is a document that asks you to trust its author. You cannot re-check the finding without re-doing the work, so you either believe it or you argue about it. That trust gap costs everyone: buyers cannot tell a rigorous vendor from a fluent one, good vendors cannot prove they are better, and remediation stalls in "is this even real" debates. The fix is old and proven: make the finding carry a proof the receiver can check in seconds, without trusting the sender at all.
What you are actually buying when you buy a pentest
A penetration test ends in a report. Findings, severities, screenshots, recommendations. It looks authoritative. But consider what the report actually is: a set of claims, written by a person or a tool, that you are asked to accept largely on reputation. For any given finding, can you independently confirm it is real, right now, without hiring someone to reproduce it? Usually not. The evidence is a screenshot and a paragraph. The proof, the thing that would let you verify it yourself, is not in the document.
This is the trust gap, and it quietly taxes the entire security economy. As a buyer, you cannot distinguish a vendor who verified every finding from one who ran a scanner and pasted the output, because both hand you a confident PDF. As a good vendor, you cannot charge for your rigor, because rigor is invisible in the deliverable. And as an engineering team receiving the report, you burn days in "we do not think this is exploitable" arguments, because there is no artifact to settle them.
Economists have a name for a market where buyers cannot tell quality apart before purchase: a market for lemons. Quality gets driven out, because it cannot command a premium it cannot prove. Security findings have exactly this structure, and the unverifiable PDF is why.
Screenshots are not proof
The current standard of evidence is a screenshot and a description. Both are trivially wrong or stale. A screenshot shows a moment; it does not reproduce. A description is the author's interpretation. Neither lets the receiver re-run the finding and see it fire. When the finding is wrong, a false positive dressed in confident prose, the receiver has no cheap way to know, so they either waste time disproving it or, worse, learn to dismiss that vendor's findings wholesale, including the true ones.
The problem is not that authors are dishonest. It is that the format has no mechanism for the receiver to check. Trust is doing all the work, and trust does not scale, does not transfer, and does not survive the first bad finding.
The fix computer science already has: proof-carrying artifacts
There is a well-established idea for exactly this shape of problem. In the 1990s, proof-carrying code let a program ship with a machine-checkable proof of its own safety, so the host could verify the proof cheaply and did not have to trust the code's origin at all. The trust moved from the sender to a small, independent checker.
Apply the same idea to findings. A vulnerability report should be a portable, signed, content-pinned artifact that a receiver re-checks in seconds without trusting the sender. Not a screenshot: a bundle that carries what is needed to reproduce the finding and confirm it fires. For a memory-safety bug, the minimized trigger input, the sanitizer output, the reproduction steps. For a web finding, the request and the out-of-band witness that proves the effect reached a system the tester controlled. The receiver runs one check. The finding either reproduces or it does not. The debate is over before it starts.
This flips the economics. When every finding carries its own proof, a buyer can tell a verified report from an asserted one at a glance, a rigorous vendor can finally charge for rigor, and remediation teams stop arguing about reality and start fixing. The market for lemons separates back into a market where quality is visible and priced.
There is a threat model worth naming: the reporter who wants credit for findings they did not really prove, "green-washing." A proof-carrying format defends against exactly this, because a finding with no reproducible witness simply does not check. The format makes honesty the path of least resistance.
How Nemesis builds it in
This is not an add-on for us; it is the core thesis. Nemesis Red and Nemesis Forge are built so that a finding is a byproduct of its own proof. Nothing reaches a report unless a deterministic oracle confirmed it, and the artifact that confirmed it travels with the finding.
For memory-safety discoveries, Forge assembles a disclosure packet: the reproducing trigger, the sanitizer-typed crash, the root cause, the exploitability grade actually reached, and a suggested fix. A maintainer verifies it by running one command. For web and network findings, Red confirms with an out-of-band signal the attacker controls but benign traffic cannot produce, and the report carries that evidence. In both cases the claim is not "trust us, it is exploitable." It is "here is the artifact, check it yourself."
We hold ourselves to the same standard we are asking buyers to demand. We report the highest rung a finding actually reached and downgrade honestly. We distinguish a reproduced known-CVE from a novel discovery. And when a high-severity CVE is a version-based association rather than an exploited path, the report says so. The proof is what makes those honest distinctions legible instead of just claimed.
What buyers and receivers should demand
You can force this shift from the buy side, and it costs you nothing but a sentence in the RFP:
- "Every finding ships with a machine-checkable proof I can verify without your help." Put it in the contract. Watch which vendors flinch.
- Ask to re-check one finding yourself. A vendor whose findings carry proof will hand you the artifact. A vendor selling screenshots will explain why that is hard.
- Require the honest distinctions. Reproduced-known versus novel. Highest proven rung, not highest imagined. Version-association versus exploited.
- Value what does not appear. A report that omits the findings it could not prove is worth more than one that includes everything it could imagine.
The pentest PDF has been the industry's deliverable for twenty years, and for twenty years it has asked you to trust rather than verify. The tools now exist to hand you proof instead. Once you have held a finding you could check in ten seconds, the confident-paragraph version stops being good enough.
Nemesis Red and Nemesis Forge produce proof-carrying findings: portable, signed artifacts a receiver re-checks without trusting the sender. Prove, do not just assert. nemesislabs.xyz