90 30 days: Project Zero ends the soak era
90→30 days: Project Zero ends the soak era Google's Project Zero will now disclose a vulnerability 90 days after telling the vendor — fixed or not — and that window shrinks to 60 days on February 2, 2027, and to 30 day
90→30 days: Project Zero ends the soak era
Google's Project Zero will now disclose a vulnerability 90 days after telling the vendor — fixed or not — and that window shrinks to 60 days on February 2, 2027, and to 30 days on January 3, 2028. The old ceiling was 120 days. The new one is a 75% cut, phased in over 416 days.
What changed
Since 2021, Project Zero followed a "90 + 30" policy: vendors got up to 90 days to remediate, plus a 30-day "soak time" for the patch to roll out before details went public. The new policy, announced November 13, is "Full X": a vulnerability is disclosed X days after it is reported to the vendor, whether a patch exists or not.
| Rule | Disclosure after report | vs old 120-day ceiling |
|---|---|---|
| Full 90 (now) | 90 days | −25% |
| Full 60 (Feb 2, 2027) | 60 days | −50% |
| Full 30 (Jan 3, 2028) | 30 days | −75% |
The phase-in is not symmetric: Full 60 arrives 81 days after the announcement, but Full 30 is 416 days out — vendors get a short runway to 60, then a full year to prepare for 30.
Most special cases are gone with the soak time, including the grace period and the variant policy. Three exceptions remain: vulnerabilities actively exploited in the wild (handled under Google's application-security disclosure policy), vulnerabilities whose details are already public, and cases where the vendor itself requests disclosure. Hardware gets a carve-out in spirit — Project Zero notes it has granted rare exceptions before, including Spectre and Meltdown, and will continue to do so.
Why: the patch is no longer a secret
Project Zero's argument is that AI broke the assumption the old timeline rested on. Two claims, quoted from the announcement:
- "LLMs have increased the speed at which attackers can find and exploit vulnerabilities, alongside the risk that multiple parties, including malicious ones, discover the same bug."
- "Zero patch-to-exploitation time is a reasonable, though imperfect, model of attacker behavior."
The logic: if attackers can reverse-engineer a patch into an exploit almost immediately, the 30-day soak period after a fix does not protect users — it just delays the information defenders need. "Patch gap," the time between a fix being released and users installing it, is now the thing vendors are told to shrink, "either by reducing patch rollout time or using other strategies to protect users while remediation is in progress."
Volume is the other driver. Project Zero says it is "finding several vulnerabilities a week in targets where we once found a few vulnerabilities a year." Put numbers on their words: a few a year is roughly 3; several a week is roughly 150 a year. That is about a 50x increase in finding rate — and it is also why the old policy's negotiation-heavy machinery, including agreeing with the vendor on whether a bug counts as fixed, had become "quickly unmanageable."
Severity no longer matters — and that is the point
The most counterintuitive part of the new policy is what it refuses to do: severity plays no role in disclosure timing. Project Zero's reasoning is blunt — "a vulnerability's severity does not affect the likelihood that it will be discovered by attackers, only its impact on users." A low-severity bug is as findable as a critical one, so delaying its disclosure does not reduce anyone's exposure; it only hides information.
This is also the part vendors pushed back on during consultation, and Project Zero says so openly: vendors worried that an aggressive deadline would make them prioritize newly reported bugs over more severe ones, and that a deadline some vendors cannot meet would lead them to stop trying. The phased 90 → 60 → 30 schedule is the compromise — "challenging but realistic," in their words, with the hope that vendors improve remediation infrastructure along the way rather than giving up.
What "fixed" means now: a status update, not a verdict
Under the old policy, whether a bug was fixed was a decision point that moved the disclosure date. Under Full X, it is not. Project Zero says it will still track whether bugs are fixed and communicate when they are not — but that will not change the date. The disclosure clock is now purely a function of the report date, which is the part that makes the policy automatable: no negotiation, no judgment call, just a calendar.
That automation is the real story. A disclosure policy that needs a human to decide "is this fixed?" for every bug does not scale to several findings a week. A policy that reads the report date and counts forward does.
The takeaway
The old deal was: tell us privately, fix it in 90 days, and you get 30 more days of quiet while the patch rolls out. The new deal is: you get 90 days, then 60, then 30 — and the quiet period is gone, because Project Zero believes AI has already ended it. If you ship software that Project Zero looks at, the date that matters is no longer your patch date. It is the day they emailed you.
Sources: Google Project Zero, "Policy and Disclosure: 2026 Edition" (announced November 13, 2026; Hacker News thread November 14). All arithmetic — the 25%/50%/75% cuts, the 81- and 416-day intervals, the ~50x finding-rate estimate — is my own, computed from the policy's published dates and wording.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.