- Google Project Zero has announced a schedule: disclosure 90 days after reporting now, 60 days from February 2, 2027, and 30 days from January 3, 2028.
- The team says AI tools speed up attackers, so secrecy after a bug report protects users less than it once did, though it still sees short-term benefits.
- Customers should ask vendors how fast they fix bugs and what they can do to protect users before a fix ships.
The quiet period was built for slower attackers
Embargoes on bug details rest on a simple logic: attackers were not already looking. The researcher stays quiet while the vendor builds a fix. The public learns the details later.
Google Project Zero now says that logic has weakened. On November 13, the team announced a new disclosure policy. Its reasoning is blunt: AI-assisted discovery and exploitation have made the old timeline "clearly insufficient."
What the new policy says
Since 2021, Project Zero has followed a "90 + 30" policy. Vendors got up to 90 days to fix a bug, plus 30 more days of "soak time" for the patch to reach users.
That ends. The new rule is simple: a vulnerability is disclosed a fixed number of days after it is reported to the vendor. The number shrinks on a schedule.
The policy starts as "Full 90" today. The team says it will move to "Full 60" on February 2, 2027, and to "Full 30" on January 3, 2028.
Project Zero is also removing most special cases, including the grace period and the variant policy. Three exceptions remain. Bugs already exploited in the wild follow Google's application security disclosure policy. Project Zero may publish details already made public by others. And it will publish if the vendor asks. The team also says it may still grant rare one-off exceptions, as it did for Spectre and Meltdown.
Why the team says the old timeline fails
Project Zero gives three reasons. The first is speed. The team says large language models (LLMs) have increased how fast attackers can find and exploit bugs. They have also raised the chance that several parties, including malicious ones, find the same bug.
The second reason is how attackers use a fix. A patch shows what changed in the software. An attacker can study that change to work out the flaw and then build an exploit. Project Zero says LLMs have cut the time this takes. It calls "zero patch-to-exploitation time" a reasonable, though imperfect, model of attacker behaviour.
That undermines the soak period. Waiting after a patch ships can create what the team calls "a false sense of secrecy." Project Zero also points to the patch gap, the time between a fix being released and a user installing it. It wants vendors to shrink that gap too, or to protect users by other means while a fix rolls out.
The third reason is volume. Project Zero says it now finds several vulnerabilities a week in targets where it once found a few a year. Settling whether a bug is fixed and whether a grace period applies, case by case, is becoming unmanageable.
What vendors said, and what the team gave up
Project Zero asked the vendors it reports to most for feedback. Their main worry was that moving straight to a short deadline could expose unfixed bugs while vendors are still improving their processes.
The team accepts part of this. It says the benefits of delaying disclosure are declining, but it still sees benefits in the short term.
Vendors raised two quieter concerns. A tight deadline could push teams to fix Project Zero's bugs first, even when other reported bugs are more severe. And a deadline some vendors cannot meet might lead them to stop trying.
The staged schedule is the team's answer. It describes the path as "challenging but realistic." These are the vendors' stated concerns, not measured outcomes.
One more change matters for customers. Project Zero will keep tracking whether bugs are fixed. But "fixed" will no longer decide when a bug is disclosed. The team says more vendors are experimenting with fixes that are not patches, such as temporarily disabling a code path, which it expects to make agreeing on what counts as fixed harder.
What to ask your vendors and your own team
This policy covers bugs Project Zero reports. It does not set a rule for every researcher. But it shows how one respected team now reasons about risk, and customers can use the same reasoning.
Ask your main software suppliers how long they take to fix a serious reported bug. Ask whether they can meet 60 days, then 30. Ask what they do for customers in the days before a fix is ready, such as turning off a feature or changing a setting.
Then look inward. Ask your IT team how long a vendor patch takes to reach your machines. If the answer is weeks, a large part of the patch gap sits with you, whatever your vendor does.
The lesson is that secrecy used to buy defenders time. Project Zero says that time is now shared with attackers. The remaining advantage is how fast your vendors fix, and how fast you install.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Google Project Zero.
