Your audit was true on Tuesday. Is it still true today?
A security audit is a snapshot. “Requires PHP 7.4” quietly becomes an unsupported runtime. “Tested up to WordPress 6.8” rots the day 7.0 ships. “Bundled library is clean” ends the morning a CVE drops. Living Audits keeps those claims honest — continuously re-verified against ground truth, with signed challenges and quoted evidence delivered back to your report when they break.
How it works
Findings are born with a why
Every CRITICAL and HIGH finding carries a structured rationale written while the engine still has your code in context: the evidence that grounds it, why it earned its severity, what was assumed, and exactly what would change the assessment. Not a post-hoc justification — reasoning, captured at generation time.
Safety claims get extracted and re-verified
The facts that silently rot — your declared minimum PHP, your tested-up-to WordPress version, every pinned Composer and npm dependency — are submitted to Reverify as claims. It re-checks them against ground truth on a decay-aware cadence: OSV for dependency CVEs, endoflife.date for runtime EOL, wp.org for plugin facts, library documentation for API claims.
When the world moves, you get a challenge
A PHP version reaches end-of-life. A CVE lands in a library you bundle. Reverify pushes a signed challenge with quoted evidence back to your report — attached alongside the original finding, which is never edited. The audit stays a faithful record of what was true when it ran; the challenge tells you what changed since.
A real challenge, from our first production day
One of the first audits to run with Living Audits declared a minimum of PHP 7.4. Within seconds of the audit completing, Reverify had checked the claim against endoflife.date and pushed back a signed challenge:
The audit didn’t change — it was accurate when it ran. But anyone reading the report now sees that the plugin’s declared minimum is an end-of-life runtime, with the primary source quoted. That’s the difference between a PDF that ages and a report that keeps watch.
Where challenges surface
On the report
A Living Audits section lists every claim with its verdict. Challenged claims show the challenge and its evidence inline; a finding-level banner marks any finding whose underlying claim moved.
In the public directory
Public audits with unresolved challenges carry an under review marker — so a plugin's grade never silently rests on expired facts.
In your pipeline
A claim.challenged webhook event fires to your registered endpoints, and Agency fleet dashboards get an alert per affected client plugin.
The rules it works under
Attach, never mutate
Challenges are additive. The original finding and report are never edited by the verifier — history stays history, and new information arrives as new information.
Safety-positive claims only
We never submit our own vulnerability findings for verification — a finding doesn't rot, it was true when found. Only claims of safety and currency are submitted, because those are the ones that quietly expire. Dependencies your audit already flagged are excluded.
Verifiable claims only
Claims are only submitted when an independent checker can actually test them — runtime versions, dependency CVEs, wp.org facts, third-party library APIs. Internal behaviour ('this query has no LIMIT') is yours to judge with the rationale we give you, not something an external service pretends to verify.
Never in the way
Reverification is best-effort and asynchronous. If Reverify is unreachable your audit completes normally — claims simply resume on the next hourly sync. It can never block, delay, or fail an audit.
Included on every plan, from Free up
Every audit — free, paid, API, or MCP — submits its claims and receives challenges. No configuration, no add-on, no token cost.