Project Zero Updates Its Vulnerability Disclosure Policy

Four years on, Project Zero’s policy evolves again.

Since 2021, the Google-hosted security research team has followed a model known as “90 + 30″*. Any editor to whom a vulnerability is reported has 90 days to patch it before it is made public. For those fixed within the deadline, the technical details are published only 30 days later — a window intended to cover the patch adoption time. There is a 90-day grace period, grantable if patching can be completed within 104 days.

Project Zero experiments with an early disclosure

This policy has had little effect on one aspect: the time between the publication of a fix and its diffusion in the supply chain of software. Project Zero points to its work on chipsets and their drivers as evidence: they demonstrated how this diffusion delay contributes to lengthening the lifecycle of vulnerabilities.

A new approach is therefore being tested. The 90-day window remains, but with an additional step at the start of the process. About a week after reporting a vulnerability to a vendor, Project Zero will publicly announce its existence. It will specify the supplier or the open-source project involved, the affected product, the date of the report and the expiration date of the 90-day window.

These elements are intended to address a downstream signal in the supply chain… and to stimulate better upstream communication. Project Zero acknowledges that the approach could cause headaches for vendors without downstream ecosystems, by drawing attention to vulnerabilities that only they can fix. But these vendors represent a minority of the vulnerabilities addressed. The overall benefit of the approach would therefore outweigh these drawbacks.

* This cycle does not apply to actively exploited flaws. These are made public 7 days after their disclosure (a 3-day grace period). Project Zero also waits 30 days to publish the technical details.