Name and Shame? Google's Team to Expose Unfixed Security Flaws

Google's Project Zero Introduces New Vulnerability Disclosure Policy

Google’s security team, known as Project Zero, is implementing a new approach to how it discloses software vulnerabilities. This change aims to improve the speed and effectiveness of patch rollouts but has sparked some debate within the industry.

Project Zero is responsible for identifying previously unknown software bugs, often referred to as zero-day vulnerabilities. Traditionally, the team provided 90 days for software vendors to address these issues before making them public. If a vendor released a patch, they had an additional 30 days to allow users time to install it.

Now, the team is revising its disclosure policy. While the 90-day deadline remains in place, Project Zero will now publicly announce when it has discovered a flaw—specifically naming the vendor and product involved—within one week of reporting the issue. This new practice is currently being tested as a trial.

The shift comes as part of an effort to reduce what the team calls the “upstream patch gap.” This term refers to situations where a software vendor releases a fix for a vulnerability, but the downstream partners responsible for distributing the update fail to do so, leaving users exposed.

According to Tim Willis, head of Project Zero, the increased transparency is intended to ensure that all parties are aware of the vulnerability and can act accordingly. “We hope that this trial will encourage the creation of stronger communication channels between upstream vendors and downstream dependents relating to security, leading to faster patches and improved patch adoption for end users,” he stated.

However, the new policy also raises concerns. By disclosing the existence of flaws more quickly, there is a risk that hackers could exploit the information. To mitigate this, Project Zero will not release technical details, proof-of-concept code, or any other information that could aid attackers. The goal is to inform the public without providing a blueprint for malicious activity.

So far, the team has already disclosed two new vulnerabilities in Microsoft Windows and three flaws in Google’s “BigWave” product, which may refer to a video codec. These disclosures were made under the new policy, though the specific nature of the flaws was not shared.

The change has not gone unnoticed by some stakeholders. Willis acknowledged that the policy might cause discomfort, particularly for vendors who lack a downstream ecosystem. However, he emphasized that such cases represent a minority of the vulnerabilities reported by Project Zero.

In a previous FAQ, Project Zero defended its approach to public disclosures. It noted that many software systems have complex components, and simply stating that a vulnerability exists in a particular component does not provide actionable information to attackers. “All software of sufficient complexity will contain vulnerabilities,” the FAQ explained. “Saying things like ‘I just reported a vulnerability in the Android media server’ isn’t materially useful information for an attacker.”

As of July 29, 2025, Project Zero has 2,131 vulnerabilities with a 90-day deadline in a “New” or “Fixed” state in its issue tracker. Out of these, 95 vulnerabilities have been disclosed without a patch being made available to users.

The trial period allows the team to closely monitor the effects of the new policy. The ultimate goal is to create a fair, simple, and transparent process that benefits both software vendors and end users. By encouraging better communication and faster patching, Project Zero hopes to enhance overall software security across the board.