Google security disclosure is getting a different clock. Project Zero's new ordinary policy starts the publication timer when its researchers report a vulnerability to the responsible vendor. An early patch leaves that timer running toward the same endpoint. For some early fixes, technical details can remain private longer than under the previous ordinary rule, even as Google prepares shorter disclosure windows for the future.
TL;DR
- Current Full 90 ordinarily publishes technical details ninety days after reporting. Defined exceptions remain.
- The historical 2021 ordinary rule published details thirty days after a fix shipped within its deadline.
- Google's current policy example patches on day 47 and publishes on day 90. The historical ordinary rule calculates to day 77 for that example.
- A deadline-day fix loses the old extra month before technical disclosure. Fix timing therefore changes the direction of the comparison.
- Google plans shorter clocks in stages, while existing reports keep the policy that applied when they were submitted.
How Google security disclosure now uses the report date
Project Zero is Google's security research team. It sends a detailed technical report to the vendor or open-source project responsible for fixing a vulnerability. Its disclosure policy determines when those technical details become public in the team's tracker. The official FAQ describes the reporting and publication process.
The November 13 announcement by Natalie Silvanovich introduces Full X. The current value of X is ninety. The dedicated policy page says the vendor has that interval to make a patch available to users, and the ordinary technical disclosure endpoint stays fixed regardless of when the vulnerability is fixed.
That produces a simpler scheduling question for vendors: when did the report arrive? The answer establishes the ordinary publication date. Shipping a patch earlier still protects people who install it, but it no longer starts a separate ordinary disclosure timer.
This governs Project Zero's own reports. Other research teams and vendors can have their own workflows. Reading this policy as a universal obligation for every vulnerability report would lose the scope the team describes, including its expectations about report quality and demonstrated security impact.
What the historical post-patch rule did
Tim Willis's official 2021 policy table supplies the historical comparison. For an ordinary issue fixed within ninety days, technical details were published thirty days after the fix. The team called that period patch adoption time.
The practical intention was to leave time for an available update to reach users before researchers released a public technical explanation. That explanation can help defenders assess risk, understand a fix and investigate related weaknesses. The historical article also acknowledged the defensive costs of waiting for details, including prioritizing deployment and testing patch efficacy.
The shorthand "90 plus 30" can obscure the early-fix case. A vendor fixing a bug well before its deadline started the post-patch interval at that early fix. Earlier patches could bring disclosure forward within that combined window. Historical grace periods and actively exploited cases had additional rules, so this article keeps the comparison to the ordinary fixed-within-deadline case.
This also explains why removing a post-patch interval does not necessarily move every publication earlier. The event that starts the clock changes. That is the important part of the diff, and it is easy to miss when a headline only lists the length of the window.
A patch release and a protected user are different milestones
Silvanovich defines the patch gap as the time between a security fix being released and the user installing the relevant update. An available patch can sit between a vendor's release process and the systems that need it. Publication timing cannot tell you that every installation has reached the fixed version.
The announcement argues that AI has accelerated vulnerability discovery and the analysis of public patches. Its strongest formulation is that near-zero patch-to-exploitation time is a reasonable, imperfect planning model. The word imperfect belongs with that claim. This episode contains no independent measurement proving that every patch becomes an attack immediately.
Google's policy reasoning is that a public fix may already provide information about a weakness while the detailed report remains private. It therefore wants vendors to reduce rollout time or use other strategies to protect users while remediation proceeds. That puts pressure on the release-to-installation interval as well as patch development.
For developers responsible for deployed software, the useful distinction is between the existence of a fix and evidence that it reached the relevant systems. Ask suppliers for actionable details and check deployment through your normal update process. A calendar for technical publication answers a different question from the installed version of a dependency or application.
Why Google is shortening the clocks gradually
The current ordinary policy is Full 90. Google plans Full 60 for February 2, 2027, and Full 30 for January 3, 2028. Those are future stages. A reader encountering the policy today should keep the current window separate from the planned shorter ones.
The announcement says Project Zero consulted vendors that receive many of its reports. They raised concerns that an abrupt change could expose unfixed vulnerabilities while companies were still improving their remediation processes. They also worried that a short deadline could distort repair priorities, or cause a vendor facing an impossible target to give up on meeting it.
A disclosure schedule can create pressure to improve a release process. It still leaves the work of developing, checking and delivering a fix with the organizations responsible for the software. The gradual plan is Google's attempt to set a challenging schedule that vendors can realistically move toward.
There is an important boundary for existing work. The official FAQ says a vulnerability stays subject to the disclosure policy in effect when it was reported. The policy applicable to a specific issue can be found in the report. The announcement therefore does not retrospectively replace the clock on every existing report.
Scope, severity and exceptions still matter
Project Zero says it reports vulnerabilities with substantial severity and demonstrated security impact. It holds itself to high standards for reproducibility, readability and reachability. The announcement acknowledges that vendors can reasonably treat low-quality reports differently. A large volume of vague reports would not establish that this policy's assumptions had been met.
Severity still matters to vendors prioritizing fixes. Google's stated reasoning is that severity affects the impact on users, while it does not determine whether attackers rediscover a bug. A vendor's risk ranking and the research team's publication calendar can consequently arrive at different decisions about the same report.
The dedicated policy keeps defined exceptions. Vulnerabilities actively exploited against real users have a seven-day disclosure timeline. Technical details made public by another party can trigger immediate disclosure. The affected vendor can request publication earlier than the ordinary date. Rare exceptions to prevent widespread user harm also remain possible.
Fix tracking continues. Silvanovich says Project Zero still plans to track whether bugs are fixed and communicate when they are not. The change removes fix status as a decision point for the ordinary disclosure date. That distinction lets the team discuss how users are protected without making every publication schedule depend on a negotiated binary judgment about a fix.
Google's worked example shows both sides of the tradeoff
The current policy page provides an ordinary example: a vendor patches a security issue forty-seven days after Project Zero reports it, and details become public on day ninety. That is an illustration in the policy, with no actual incident or user deployment measurement attached.
Applying the official historical ordinary rule produces a different endpoint. Forty-seven plus the thirty-day adoption period calculates to seventy-seven. The current example's day ninety arrives thirteen days later. The patch is available on the same day in both sides of this comparison; the wait for the technical explanation changes.
| Ordinary illustration | Historical publication calculation | Current publication |
|---|---|---|
| Patch on day 47 | Day 77, calculated as 47 plus 30 | Day 90 |
| Patch at the deadline | The old extra month follows the fix | Publication at the deadline |
The second row supplies the balance. For a deadline-day fix, the old extra month of waiting disappears. The change can make publication later for an early fix and earlier for a late fix. User installation remains a separate, unknown event in these policy examples.
That is why I would keep the report date, patch release, deployment and technical disclosure separate when discussing this change. Collapsing them into a single word such as fixed makes the calendar sound more protective than it can demonstrate on its own.
Verdict: NEEDS REVIEW
I stamped this NEEDS REVIEW. I'd judge the policy by how quickly users actually get protected, while watching the early-fix disclosure tradeoff. A predictable date is useful for coordination. The harder outcome is getting available protection onto the systems people use, without treating a private technical report as proof that nobody else understands the weakness.
What slows your team's security updates most: testing, rollout or restarts?
FAQ
Is Full 30 the current ordinary rule? Current Full 90 remains in place. Full 60 and Full 30 are planned future stages with separately stated start dates.
Does an early fix automatically make Project Zero publish early? The ordinary current report-date clock remains fixed. Defined exceptions, including vendor-requested earlier publication, still apply.
Does the new policy change every existing report? The official FAQ says reports retain the policy that applied when they were reported.
Did this episode measure real exploitation or patch rollout? It compares Google's ordinary policy example with its official historical rule. The example and arithmetic establish a disclosure-timing comparison; they supply no measured user-installation time or exploitation benchmark.
Sources
- Natalie Silvanovich, Policy and Disclosure: 2026 Edition
- Current Full X policy and examples
- Tim Willis, Policy and Disclosure: 2021 Edition
- Official disclosure FAQ
- Hacker News discussion; opinions only
- Fresh DGMAGAZINE coverage; primary-source synthesis
- TLDR synopsis; no independent benchmark
Cover credit
The whole portrait-based cover artwork adapts World Economic Forum's Pichai portrait, via Wikimedia Commons, CC BY 3.0, from the linked original WEF video. Changes are background removal, resize, placement and new typography. Pichai identifies Google; Natalie Silvanovich authored the policy. No endorsement or current personal reaction is implied. The article does not embed the film reaction GIF.
This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.
