A finding without a reproducible PoC request and response is an opinion. Enterprise and public-sector audits run on proof, not on a CSV of severities.
The hardest question in an audit is never "do you have findings". It is "prove this one was real, and prove that one was fixed". A spreadsheet of severities answers neither. What answers both is the exact request that triggered the issue, the response that proved it, the fix that closed it, and a timestamped trail no one can quietly rewrite. apPosture treats that chain as part of the finding itself, not as paperwork you assemble the week before the assessor arrives.
A finding without a reproducible proof of concept is an opinion. Enterprise and public-sector audits do not run on opinions; they run on evidence a reviewer can follow end to end and reconstruct independently. So we store the proof at the moment the finding is raised, and we store it in a form a regulator can argue from but cannot argue with.
Most tools hand an auditor a flat list and a severity column. The reviewer's real job is to walk a single finding from claim to closure: what was sent, what came back, why that response is proof, what changed in the code, and when each step happened. That is a chain, and every link has to be present or the whole thing is just an assertion.
The point of the chain is reconstruction. An assessor does not have to take "high severity" on faith; they can replay the captured request and watch the captured response confirm the boundary failed. Proof beats prose every time someone is paid to doubt you. And because the chain is attached to the finding rather than reassembled from memory, the answer is the same whether the question is asked the day the issue is found or two years later in a dispute. Continuity is what turns a pile of artifacts into evidence: one record, one fingerprint, one timeline that survives staff turnover, tool changes, and re-scans.
We do not let a finding reach "confirmed" without its full evidence payload. The fields below are not optional decoration; they are the minimum an auditor needs to verify the claim and the fix without phoning the security team. Reachable findings stay labelled reachable; only proven ones carry the confirmed status and the in-band response that earns it.
| Artifact | Stored field | What it proves |
|---|---|---|
| PoC request | method + url + attack | The exact bytes that triggered the issue, replayable as-is. |
| PoC response | evidence / exploit_evidence | The response body that confirms the leak or execution - the oracle, not an inference. |
| Secure fix | solution / ai_fix_suggestion | The concrete remediation, so closing the finding is unambiguous. |
| First seen | first_seen | When the unit of work entered the estate, anchoring the SLA clock. |
| Exploit status | exploit_status | not_tested, likely, or confirmed - the honesty bit that separates reachable from proven. |
Because findings collapse by fingerprint into a single unit of work, those artifacts accrete onto one record rather than scattering across duplicate rows. The same vulnerability seen by two scanners, or seen again next week, extends one chain instead of starting a new argument.
Storing the response that proves a leak creates an obvious hazard: the proof is itself a copy of the secret. apPosture resolves that by masking sensitive values inside the stored evidence. A credential or PII string is redacted to a recognizable but useless stub - enough to show the field was exposed, not enough to re-expose it. The secrets scanner never stores a raw value at all; every match is reduced to the first four and last two characters with the middle struck out.
This is the privacy contract that makes an evidence vault safe to hold. An auditor trusts a report more when it demonstrably does not hoard the very data it is flagging. Masked evidence is stronger evidence in any room where data-handling is itself under review.
Immutable cannot mean "we promise not to edit it". The lifecycle of a finding is written as an append-only event timeline - detected, triaged, resolved, reverified, closed - with no update and no delete path in the API. Each entry records the actor, the change, and the timestamp.
The vulnerability audit log goes one step further with a tamper-evident hash chain: every entry stores a hash computed over the previous hash plus its own content. Any retroactive edit or deletion changes one hash and breaks every link after it, so verification fails loudly instead of failing silently. The same tamper-evidence binds frozen reports to a content hash. You are not asking the auditor to believe the log was not touched; you are giving them the math to check.
When the evidence is attached to each finding the moment it is raised, audit preparation stops being a fortnight of screenshotting. The request, the proving response, the fix, the SLA clock, and the immutable history are already there. Role-scoped export - an auditor role with export_evidence and export_audit rights, and a dedicated auditor portal - hands an assessor exactly the proven evidence and nothing more, with sensitive values masked before they leave.
Evidence over heuristics is the engine's quality bar; an evidence vault is what that bar leaves behind. A shorter list, every item of which carries a replayable proof and a history that cannot be quietly rewritten, beats a long list a reviewer stops trusting at the first claim they cannot reconstruct. That is the difference between a finding an auditor questions and a finding an auditor cannot argue with.