Verified remediation
Proof of fix your auditor can check without trusting us.
When a fix holds, ProvenClosed signs what it observed: the resource, when the exposure was last seen, when it was found gone, and what the scan did and did not cover. The signed record travels inside a readable page.
Verified remediation means a fix is confirmed by evidence rather than by a status. A later scan, by the same pinned scanner that found the exposure, observes that it is gone — and ProvenClosed keeps watching for it to come back.
Why a closed ticket is not proof
A ticket marked done records that somebody believes a fix was made. Nothing in it checked that the port is shut, the certificate renewed or the bucket private. Auditors and enterprise buyers ask for something else: dated evidence that the fix held, established independently of whoever made it. Today that is usually a retest letter, bought once and true on the day it was written.
How it works
How a fix becomes verified.
Seen present
A scan records the exposure and the exact scanner build that saw it.
Fixed by your team
ProvenClosed never changes your infrastructure. It tells you what to fix, first things first, and can hand it to GitHub Issues.
Seen gone
Only a later scan can mark a finding fixed. A ticket status does not count, and neither does anyone saying so.
Watched, then signed
It keeps looking. If the exposure comes back, the finding reopens as a regression. If it holds, the certificate says exactly what was observed.
The certificate
A certificate says how strong its own proof is.
Every certificate carries one of three states, decided from what was observed. The state is downgraded rather than rounded up, and the reason travels with it.
Seen, then seen gone — by the same pinned scanner, in a scan run that was recorded.
Gone, with the caveats named. For example, the scanner build changed between the two scans — so the certificate says so rather than hiding it.
Not yet seen gone. A ticket marked done does not count, and neither does anyone saying so. Only a later scan can.
What a certificate contains
- The exposure and the resource — what was found, and where.
- When it was last seen present, and when it was observed absent.
- The scanner — each image by its registry digest, and whether anyone can pull it to re-run the check.
- Coverage — what the scan looked at, and what it could not.
- The controls the check is evidence for, in SOC 2, ISO 27001 and SEBI CSCRF, with the sentence that stops them being read as an assessment. Compliance evidence.
- What it could not establish.
- A signature — a DSSE envelope, signed with a key published on this site.
- A transparency-log proof — its fingerprint, and nothing else about it, is in Sigstore's public log, so it cannot be backdated or quietly withdrawn.
How anybody checks one
- On the reader's own machine. One open-source script, verify.py, verifies the signature against the key set published here, and the transparency-log proof without contacting the log.
- No account, no call to our API. The person checking never logs in and never asks us anything.
- Tamper-evident. Change one signed byte and verification fails. The verifier re-prints every claim from the signed data, not from the page around it.
Verify a certificate, step by step
Retest evidence between VAPTs
A penetration test finds what a person can break at one moment, and a retest confirms its findings on the day it is run. ProvenClosed keeps going after both: it re-checks each fix it can observe from outside and in your AWS account, and signs what it saw. It complements a penetration test; it does not replace one, and its certificates are not VAPT certificates.
Stop saying it's fixed.
Show it.
Signed certificates come with Business and Pro, in early access. Monitoring one domain is free.