Patched vs proven patched

Ask a team whether a vulnerability is handled and the answer is a ticket state: fixed, closed, done. The ticket records that a patch shipped. It records nothing about whether the bug is actually gone in the release that is running right now — the one that went out at 17:40 on a Friday, after the dependency bump, with one service in the middle skipped because its pipeline was green.

The window did not close. It moved.

Fixes ship faster than they used to, and that is genuinely good news. But every speedup on the fix side raises the price of assuming the fix landed. Container images get rebuilt from stale caches, a redeploy fails halfway and rolls forward anyway, an environment pins an old version for a good reason that nobody remembers in three weeks. Meanwhile the scanner that stopped flagging the issue because advisory metadata changed looks identical to the scanner that stopped flagging it because the bug is gone. Neither is proof. One of them is a coincidence with a timestamp.

What counts as proof

One thing does: running the original attack again, against the system as it exists today. If the exploit path still opens, the ticket was optimistic. If it closes, you have a receipt — the attack, replayed, denied, with a date on it. Everything short of that is a well-founded hope, and auditors have started asking for the receipt rather than the hope. The public sample report shows the shape: a critical finding retested the day after the fix release and verified closed, printed next to a high that stayed open because staying open was the honest state.

Why verifying once is not verifying

A retest dates quickly. Every release after it can reopen the path: a refactor brings the pattern back, an endpoint reappears with the same broken access check, an upgrade changes how input reaches the sink. Verification decays with each deploy, so it has to be scheduled rather than performed once. That is the entire argument for a standing hunt. The retest is part of the loop, and a finding does not leave the report until the original attack has been replayed and denied — the report simply refuses to archive a fix nobody has attacked again.

The uncomfortable corollary

Take verification seriously and it has to survive contact with reality. Some attacks replay clean. Some promising approaches go nowhere, and a record that only ever shows wins was curated. That is why the advisories page — the same pipeline hunting live bug-bounty programs daily — commits in writing to publishing what held up and, where an approach did not, writing that down too. Misses next to wins is what makes the wins worth reading.

Patched is a claim about intent. Proven patched is a claim about the system, dated, by someone who tried to break it again after the fix. If your audit needs the second kind of claim, that is what the standing hunt produces every cycle — and the free check is the read-only way to see the first one.