Full Report
Posted by Tim Willis, Google Project Zero In 2021, we updated our vulnerability disclosure policy to the current "90+30" model. Our goals were to drive faster yet thorough patch development, and improve patch adoption. While we’ve seen progress, a significant challenge remains: the time it takes for a fix to actually reach an end-user's device.This delay, often called the "patch gap," is a complex problem. Many consider the patch gap to be the time between a fix being released for a security vulnerability and the user installing the relevant update. However, our work has highlighted a critical, earlier delay: the "upstream patch gap". This is the period where an upstream vendor has a fix available, but downstream dependents, who are ultimately responsible for shipping fixes to users, haven’t yet integrated it into their end product.As Project Zero's recent work has focused on foundational, upstream technologies like chipsets and their drivers, we've observed that this upstream gap significantly extends the vulnerability lifecycle. For the end user, a vulnerability isn't fixed when a patch is released from Vendor A to Vendor B; it's only fixed when they download the update and install it on their device. To shorten that entire chain, we need to address the upstream delay.To address this, we're announcing a new trial policy: Reporting Transparency.The Trial: Reporting TransparencyOur core 90-day disclosure deadline will remain in effect. However, we're adding a new step at the beginning of the process.Beginning today, within approximately one week of reporting a vulnerability to a vendor, we will publicly share that a vulnerability was discovered. We will share:The vendor or open-source project that received the report.The affected product.The date the report was filed, and when the 90-day disclosure deadline expires.This trial maintains our existing 90+30 policy, meaning vendors still have 90 days to fix a bug before it is disclosed, with a 30-day period for patch adoption if the bug is fixed before the deadline.Google Big Sleep, a collaboration between Google DeepMind and Google Project Zero, will also be trialling this policy for their vulnerability reports. The issue tracker for Google Big Sleep is at goo.gle/bigsleepWhy the Change? Increased Transparency to Close the GapThe primary goal of this trial is to shrink the upstream patch gap by increasing transparency. By providing an early signal that a vulnerability has been reported upstream, we can better inform downstream dependents. For our small set of issues, they will have an additional source of information to monitor for issues that may affect their users. 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.This data will make it easier for researchers and the public to track how long it takes for a fix to travel from the initial report, all the way to a user's device (which is especially important if the fix never arrives!)Will this help attackers?No — we anticipate that in the initial phase of this trial, there may be increased public attention on unfixed bugs. We want to be clear: no technical details, proof-of-concept code, or information that we believe would materially assist discovery will be released until the deadline. Reporting Transparency is an alert, not a blueprint for attackers.We understand that for some vendors without a downstream ecosystem, this policy may create unwelcome noise and attention for vulnerabilities that only they can address. However, these vendors now represent the minority of vulnerabilities reported by Project Zero. We believe the benefits of a fair, simple, consistent and transparent policy outweigh the risk of inconvenience to a small number of vendors. That said, in 2025, we hope that the industry consensus is that the mere existence of vulnerabilities in software is neither surprising nor alarming. End users are more aware of the importance of security updates than ever before. It's widely accepted as fact that any system of moderate complexity will have vulnerabilities, and systems that were considered impenetrable in the past have been shown to be vulnerable in retrospect. This is a trial, and we will be closely monitoring its effects. We hope it achieves our ultimate goal: a safer ecosystem where vulnerabilities are remediated not just in an upstream code repository, but on the devices, systems and services that people use every day. We look forward to sharing our findings and continuing to evolve our policies to meet the challenges of the ever-changing security landscape.
Analysis Summary
# Best Practices: Vulnerability Disclosure and Patch Management Transparency
## Overview
These practices center on enhancing the security ecosystem by improving the speed and effectiveness of vulnerability remediation, specifically by addressing the "upstream patch gap"—the delay between an upstream vendor fixing a bug and downstream dependents integrating and deploying that fix to end-users. The focus is on increasing transparency surrounding the disclosure process to drive faster communication and patch adoption throughout the supply chain.
## Key Recommendations
### Immediate Actions
1. **Adhere Strictly to the 90-Day Disclosure Policy:** Maintain the core 90-day deadline for vendors to release a complete fix for a reported vulnerability, followed by a 30-day adoption grace period if the fix arrives early.
2. **Implement Reporting Transparency Notification:** Immediately (within approximately one week) of reporting a vulnerability to a vendor, publicly share that a report was filed. This notification must *only* include:
* The affected vendor or open-source project.
* The affected product category.
* The date the report was filed.
* The calculated 90-day disclosure deadline expiration date.
3. **Ensure No Technical Details Are Disclosed Prematurely:** Explicitly withhold any technical details, proof-of-concept (PoC) code, or information that could materially assist in exploitation until the disclosure deadline is reached.
### Short-term Improvements (1-3 months)
1. **Establish Downstream Dependency Monitoring:** Downstream organizations (integrators, distributors) must actively monitor public transparency reports for vulnerabilities reported to their upstream suppliers (e.g., chipset vendors, core library maintainers).
2. **Strengthen Internal Communication Channels:** Develop and test established communication channels between security teams and product integration/release teams to rapidly assess and prioritize upstream fixes upon initial public notification (Reporting Transparency).
### Long-term Strategy (3+ months)
1. **Formalize Upstream-Downstream Security SLAs:** Work with key upstream vendors to define Service Level Agreements (SLAs) or memoranda regarding the expected time frame for receiving finalized patches and integration support documentation once an upstream fix is released.
2. **Measure and Report End-to-End Patch Gap:** Develop metrics to track not just the upstream fix release date, but the complete lifecycle: from initial report, to upstream fix, to dependent integration, and finally, to end-user installation. Use this data to identify persistent delays in the development pipeline.
3. **Advocate for Ecosystem Consensus on Transparency:** Promote industry consensus that the existence of security vulnerabilities is normal, shifting focus from secrecy to the speed and reliability of remediation.
## Implementation Guidance
### For Small Organizations
- **Prioritize Critical Updates:** Focus patching resources almost exclusively on vulnerabilities identified through transparency channels that directly affect your core business functions or internet-facing services, using the early public alert as a high-urgency flag.
- **Streamline Patch Review:** Develop a streamlined, risk-based process for quickly vetting and deploying necessary patches received from upstream suppliers, minimizing regression testing delays for confirmed security fixes.
### For Medium Organizations
- **Develop Integration Tracking:** Implement a tracking system to map externally reported vulnerabilities (especially those announced via Reporting Transparency) to all internal products that rely on the affected component.
- **Resource Allocation:** Dedicate specific engineering resources to expedite the integration of high-severity upstream patches, treating the public announcement as a trigger for a pre-planned accelerated development cycle.
### For Large Enterprises
- **Automated Dependency Mapping:** Invest in Software Composition Analysis (SCA) tools or internal asset management databases capable of mapping software dependencies across the entire product matrix to quickly ascertain exposure to reported vulnerabilities.
- **Supply Chain Coordination:** Establish formal working groups or security liaison roles dedicated solely to coordinating timely security patch integration with major upstream software and hardware providers.
- **Proactive Monitoring:** Assign teams to continuously monitor specialized issue trackers (like the one mentioned for Google Big Sleep) and vendor-specific security bulletins alerted via Project Zero's transparency trial.
## Configuration Examples
*(No specific configuration commands or code snippets were provided in the source material, as the article focuses on policy and process rather than technical configuration.)*
## Compliance Alignment
The practices align with the spirit, if not the direct mandate, of major compliance standards by focusing on vulnerability management and timely remediation:
- **NIST Cybersecurity Framework (CSF):** Primarily aligns with the **Identify** (Asset Management, Risk Assessment) and **Protect** (Maintenance) functions concerning supply chain risk.
- **ISO/IEC 27001:** Supports Annex A.14 (System Acquisition, Development, and Maintenance), specifically concerning secure development policies and vulnerability management.
- **CIS Critical Security Controls (v8):** Strongly supports **Control 1** (Inventory and Control of Enterprise Assets) through dependency mapping, and **Control 7** (Vulnerability Management) through structured remediation timelines.
## Common Pitfalls to Avoid
- **Treating Transparency as Exploitation Information:** Do not mistake the announcement of a reported vulnerability for a public technical advisory. Releasing internal technical details prematurely violates established disclosure norms.
- **Ignoring Upstream Alerts:** Downstream dependents must not wait for official notification from their immediate suppliers if they become aware of an issue via the upstream transparency announcement. The early signal must trigger action.
- **Over-engineering the Fix Verification:** While thorough testing is vital, excessive layers of review or unnecessary feature backlogs should be bypassed for confirmed, high-risk security patches announced during the disclosure window to avoid contributing to the patch gap.
## Resources
- **Google Project Zero 90+30 Disclosure Policy:** (Reference the full official policy document for internal compliance guidelines)
- **Vulnerability Disclosure Policy Home Page:** (Link to the official Project Zero policy page for current deadlines)
- **Reporting Transparency Site:** (Link to the specific informational page detailing the public sharing of report filing dates)