Google Ditches Patch-Time Bug Disclosure in Favor of 90-Day Policy


Google’s Project Zero bug-hunting team is making a big change to its vulnerability disclosure policies. Full details on any vulnerability will be made public 90 days after discovery, regardless of when the bug is fixed. That means that whether it’s patched on Day 20 or Day 120, bug details will go public at 90 days. The more notable part of the announcement is Project Zero’s decision to wait to disclose bug details until 90 days elapses, even if a patch becomes available before then. The rationale for abandoning the group’s previous coordinated disclosure policy, according to Project Zero researcher Tim Willis, is to ensure that fixes are thorough and not just rushed out as quickly as possible. The idea is to avoid opening the door to incomplete patches that cybercriminals can successfully probe for weaknesses to exploit. [![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>) “For the last five years, the team has used its vulnerability disclosure policy to focus on one primary goal: Faster patch development,” explained Willis, [in a posting](<https://googleprojectzero.blogspot.com/2020/01/policy-and-disclosure-2020-edition.html>) on Tuesday on the policy changes. “If patches take a long time to develop and deploy, then we quickly fall behind the curve: more bugs are introduced than vendors can fix and a herculean effort is required to get things back on track.” However, “too many times, we’ve seen vendors patch reported vulnerabilities by papering over the cracks and not considering variants or addressing the root cause of a vulnerability,” he added. “One concern here is that our policy goal of faster patch development may exacerbate this problem, making it far too easy for attackers to revive their exploits and carry on attacking users with little fuss.” The change also allows vendors more time to get patches quietly out to affected partners and customers before details go public, Willis said – in theory improving patch adoption and reducing cybercriminals’ windows for public exploitation of disclosed vulnerabilities. As for whether the move is the right one, researchers in the vulnerability-hunting business applauded the change. “Having this additional breathing room in the disclosure timeline will hopefully lead to better patches, as there will be more time to do a full analysis of the vulnerability,” Josh Komoroske, senior DevOps engineer at StackRox, told Threatpost. “Improving user adoption of any fixes prior to public disclosure is also massively beneficial. Hopefully these changes will have these desired side effects, and improve the ecosystem overall.” HackerOne CTO and co-founder Alex Rice also told Threatpost, “The trade-offs involved are complicated, with far-reaching implications in the real world. There are no easy answers or perfect policies in vulnerability disclosure. It is promising to see leaders in this space such as Project Zero continuing to evoke a mindset of continuous improvement. We’ll be closely following the results of this new policy change in 2020.” [![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/01/08111152/Google-Project-Zero.png)](<https://media.threatpost.com/wp-content/uploads/sites/103/2020/01/08111152/Google-Project-Zero.png>) Casey Ellis, CTO, founder and chairman at Bugcrowd, meanwhile called the move a “novel update.” “Project Zero’s policy and disclosure update is a solid concession given the amount of time it can take to get a security patch fully deployed to users, even when a vendor fixes the bug quickly,” he said. “The right kind of pressure can be a good thing when it comes to vulnerability finds and fixes, and this is what Google is trying to optimize through its policy. Creating efficient patch developments, but avoiding hasty rollouts, is Project Zero’s goal, and Google is moving the industry forward with this policy by motivating developers to prioritize security. The policy’s delayed disclosure notice is a smart move – It relieves the incentive to rush patch development into the wild, which in turn reduces the potential for poor security outcomes as a product of their research.” He added, “It’s certainly a novel update to standard coordinated vulnerability disclosure (CVD) practices, and it’ll be interesting to see how successful this policy update is throughout the year.” The policy goes into effect for bugs that have been found from Jan. 1 on, and it should be noted that the change is merely in a trial phase; Willis said that Google will make the decision whether or not to permanently institute the change at the end of 2020. A 90-day disclosure _deadline_ at Project Zero has been in place for a while, meaning that if an affected vendor doesn’t fix a vulnerability by then or ask for more time (Project Zero does allow a 15-day grace period upon request), details will be released at 90 days, regardless. And according to Willis, this has been effective as an incentive to patch: About 98 percent of the company’s vulnerability reports are now fixed within the 90-day window, compared to many taking upwards of six months to fix before that deadline was enacted in 2015, he said. Google’s intention is to standardize its procedures, but one researcher told Threatpost that vulnerability disclosure timeline policies should be flexible enough to take into account the specific risk of certain vulnerabilities to customers. “Sometimes we focus too much on the vendor rather than the customer; responsible disclosure should prioritize notifying customers of a vulnerability with the intention of reducing the risks, by either making the vulnerability public so they are aware that a risk exists (applying hardening to reduce the risks); or by [supplying] a vendor patch,” Joseph Carson, chief security scientist at Thycotic, told Threatpost. “Difficulty in patching systems should also be taken into consideration, as even with public vulnerability disclosures, most systems remain unpatched for much longer — even years. Responsible disclosure is too broad today and needs to really put the customer first.” _**Concerned about mobile security? **_[**Check out our free Threatpost webinar,**](<https://attendee.gotowebinar.com/register/7679724086205178371?source=art>) _**Top 8 Best Practices for Mobile App Security**__**, on Jan. 22 at 2 p.m. ET. **_**_Poorly secured apps can lead to malware, data breaches and legal/regulatory trouble. Join our experts to discuss the secrets of building a secure mobile strategy, one app at a time._**_** **_[_**Click here to register**_](<https://attendee.gotowebinar.com/register/7679724086205178371?source=art>)_**.**_