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 Management and Patch Cycle Optimization
## Overview
These practices are derived from the need to reduce the "patch gap"—the delay between when a security fix (patch) becomes available from an upstream vendor and when that fix is successfully deployed to the end-user device. The key focus is on leveraging transparency to accelerate the integration and adoption of upstream fixes across complex software dependency chains.
## Key Recommendations
### Immediate Actions (Goal: Establish Transparency Monitoring)
1. **Establish Upstream Vulnerability Monitoring:** Designate a team or system to actively monitor public disclosures regarding upstream vulnerabilities reported to key underlying technology vendors (e.g., chipset manufacturers, core OS developers).
2. **Implement Early Alert Response Protocol:** Create an internal process to immediately triage vulnerabilities that are publicly disclosed shortly after vendor reporting (based on a transparency policy like the "Reporting Transparency" trial), even before full public technical details are available.
3. **Identify Critical Upstream Dependencies:** Create an initial inventory of core foundational technologies (e.g., operating systems, drivers, firmware components) that your organization relies on and track which downstream products utilize them.
### Short-term Improvements (1-3 months) (Goal: Reduce Upstream Patch Gap)
1. **Formalize Vendor Communication Channels (Upstream/Downstream):** Document and strengthen formal communication protocols between your team and vendors whose security fixes you depend on. Ensure there are direct contacts for expedited security communications.
2. **Integrate Upstream Disclosure Timelines:** For every tracked upstream dependency, establish an internal risk deadline based on the vendor's public disclosure commitment (e.g., 90 days) and calculate an internal remediation target that precedes the final public disclosure date.
3. **Develop Early Integration Testing Batches:** Prioritize integration and testing for patches originating from critical upstream dependencies as soon as they are released to dependents, rather than waiting for the standard quarterly or monthly release cycle.
### Long-term Strategy (3+ months) (Goal: Automate and Standardize Patch Adoption)
1. **Automate Dependency Mapping and Tracking:** Implement tools or processes to continuously map software Bill of Materials (SBOM) dependencies against known vendor vulnerability feeds to automatically flag internal products affected by newly reported upstream issues.
2. **Incentivize Patch Adoption Metrics:** Integrate metrics for the time taken to deploy upstream fixes into team performance indicators for development, operations, and release management teams.
3. **Establish Ecosystem Security Contracts:** Negotiate Service Level Objectives (SLOs) with key downstream partners regarding the maximum allowable "upstream patch gap" before their patch release deadline.
4. **Foster Cross-Vendor Security Dialogue:** Participate in or initiate industry working groups focused on establishing standards for sharing vulnerability fix status between interdependent vendors to proactively close communication gaps.
## Implementation Guidance
### For Small Organizations
- **Focus on Consolidation:** Minimize the number of disparate foundational technologies used to reduce the breadth of upstream monitoring required.
- **Manual High-Priority Triage:** Manually review public "alert" disclosures weekly. If an alert mentions a core dependency, treat it as a critical pre-patch alert and prioritize immediately verifying if the vendor has released a fix package to you.
- **Utilize Vendor Security Bulletins Directly:** Rely heavily on direct subscription feeds from primary OS, firmware, and chip vendors rather than relying solely on internal security update integration cycles.
### For Medium Organizations
- **Implement Centralized Tracking System:** Adopt a vulnerability management system capable of tracking CVEs associated not just with your product, but with their upstream components.
- **Define Triage Roles:** Assign specific personnel responsible for monitoring security advisories from the top 5 most critical upstream vendors identified in your architecture.
- **Require Dependency Disclosure:** Mandate that suppliers provide timely notification if they are integrating a patch for a newly disclosed upstream vulnerability identified via transparency programs.
### For Large Enterprises
- **Automated SBOM Scanning:** Deploy automated tools to continuously scan all in-production software builds against current vulnerability databases derived from upstream reports (including those reported via early transparency alerts).
- **Dedicated 'Patch Integration' Pipeline:** Maintain a dedicated, parallel release channel specifically for critical, zero-day, or high-profile upstream fixes that bypass standard change control windows to accelerate deployment.
- **Establish Supply Chain Risk Scorecard:** Develop a scorecard for assessing suppliers based on their publicly disclosed performance in closing their own 'upstream patch gaps' when they rely on other foundational components.
## Configuration Examples
*(The provided text does not contain specific technical configuration syntax or code examples. Guidance is therefore focused on policy and process configuration.)*
## Compliance Alignment
- **NIST SP 800-53 (Rev. 5):** Aligns closely with controls related to **RA-5 (Vulnerability Scanning)**, **RA-11 (External Information Sources)**, and **PM-9 (Supply Chain Risk Management)** due to the focus on external transparency and dependency tracking.
- **ISO/IEC 27001/27002:** Supports requirements under **A.14 (Acquisition, Development, and Maintenance of Systems)** by enforcing robust processes for handling externally sourced software components and their security updates.
- **Cybersecurity Maturity Model Certification (CMMC):** Supports practices under **SC.3.177 (Develop, document, and implement a Supply Chain Risk Management Plan)** by improving visibility into component-level risk.
## Common Pitfalls to Avoid
1. **Treating Upstream Fixes as "Vendor Responsibility Only":** Assuming that once Vendor A releases a patch to Vendor B, the security issue is closed. The organizational responsibility persists until the fix reaches the end-user device.
2. **Ignoring Early Transparency Alerts:** Dismissing early public notifications (made without technical details) as "noise." These alerts represent a valuable lead time for preparing integration and testing environments.
3. **Lacking Visibility into Deeper Layers:** Focusing patching efforts only on the application layer while neglecting vulnerabilities in deeply embedded, foundational components like drivers or chipsets, which can significantly extend the true patch gap.
4. **Over-Relying on Post-Disclosure Deadlines:** Waiting for the 90-day public disclosure deadline before initiating internal triage, thereby losing the potential time advantage provided by early internal fixes.
## Resources
- **Vulnerability Disclosure Policy Documentation:** Refer to the organization's established internal policy modeling the 90+30 framework for standard vulnerability response timelines.
- **Upstream Dependency Inventory Tool/Database:** Utilize internal Configuration Management Databases (CMDB) or specialized SBOM tools to maintain real-time dependency mapping.
- **Vendor Security Advisory Feeds:** Subscribe to official security mailing lists and RSS feeds for all critical third-party foundational technology providers.