The plan? Increase coverage and quality of security patches
Google’s Project Zero has changed its vulnerability disclosure policy to improve security patch development and adoption.
Project Zero manager Tim Willis announced in a blog post this week (January 7) that its security analysts would now adhere to a 90-day disclosure deadline by default, regardless of whether a vulnerability was fixed during that time.
Previously, details would be released to the public either when a bug was patched or after 90-days – whichever was earliest . Exceptions were made if a grace period was agreed upon between a vendor and Project Zero.
The new rules state that Project Zero tracker reports made during the grace period will now be opened automatically once patched.
“If there is mutual agreement between the vendor and Project Zero, bug reports can be opened to the public before 90-days elapse,” Willis said.
“We will try this policy for 12 months, and then consider whether to change it long-term.”
The changes took effect on January 1, 2020, and will be trialed for evaluation over the year.
While some considered the deadline to be a controversial method that may result in the release of exploits before widespread patch adoption, Google argued that a defined timeline places organizations under enough pressure to develop fixes quickly.
The team has been happy with how its previous disclosure policy has worked over the past five years, citing a 97.7% fix rate for reported vulnerabilities.
In 2019, incomplete fixes were filed as separate vulnerabilities or added to existing reports by researchers.
Now, details of incomplete fixes will be reported to the vendor and added to existing reports in order to reduce confusion and bug collisions. No new deadline will be issued for these fixes.
Willis said that the rationale behind the changes is to encourage the development of patches quickly, as faster fixes will allow vendors “additional time” for release and mainstream adoption.
Project Zero also hopes the extra time will strike the right note between robust patch development and reducing the number of cases of vendors “papering over the cracks” – resulting in exploit variants or root vulnerability causes being poorly addressed.
“We don’t expect this policy to please everyone, but we’re optimistic that it will improve on our current policy, encompasses a good balance of incentives and will be a positive step for user security,” Willis added.
Speaking to The Daily Swig, Forrester senior analyst Paul McKay said:
While some could argue that leaving vulnerabilities undisclosed publicly for longer is a bad thing for transparency and security, I actually agree with the Google Project Zero leaders in that we should be encouraging security vendors to spend more time making sure that a patch has addressed the root cause of the vulnerability and not simply a quick and dirty hot-fix because product teams backs are against the wall.
“I see this as a positive development aimed at improving the quality of the patches that are released by security and IT vendors,” McKay added.
Hugo Van den Toorn, manager of offensive security at Outpost24 told us: “Some researchers in the past might have jumped to the conclusion that when a patch comes out, it is OK to directly disclose all details – which is not the case.
“Finding vulnerabilities should not be a quantitative rat race, but rather a qualitative competition.”