Google Project Zero and Bug Disclosure Etiquette

Researchers with Google’s Project Zero are looking to make life a little better for teams tasked with patching zero-day bugs.

Earlier this month, Google’s bug hunting team announced a change in its 90-day responsible disclosure policy. In years past, when Project Zero researchers found a zero-day vulnerability in a vendor’s product or software, it would give that company a maximum of 90 days before publicly disclosing the flaw. If the vendor produced a patch within that three-month timeframe (say, within 20 days), the researchers would follow up by immediately revealing the now-patched vulnerability to the world at large.

That caused some consternation within the cybersecurity community, as sometimes flaws would be disclosed before patches were fully tested and vetted by the vendor’s developer team.

Now, Project X will give these software and IT product vendors a full 90 days to patch zero-day vulnerabilities before disclosing these bugs to the public, no matter when the software developers actually squish the bug. Google will also not offer public details about any zero-day vulnerability until after 90 days, unless there’s a prior agreement.

One reason for this change, according to the Project Zero team, is that Google originally wanted to ensure that bugs were being patched, as fast-moving threat actors were coming up with attacks based on exploiting these flaws. To that end, Google says it has largely accomplished its goal. As the team mentions in its post:

“After five years of applying a 90-day disclosure deadline, we’re proud of the results we’ve seen: vulnerabilities are being fixed faster than ever. For example, around the time Project Zero started in 2014, some issues were taking upwards of six months to fix. Fast forward to 2019, and 97.7% of our issues are fixed under deadline. That said, we know there is still room for improvement, both in industry-wide patch development speed and over the entire vulnerability management lifecycle.”

Security Etiquette

When it comes to finding and then publicly disclosing bugs in software and services, there are no specific rules of etiquette or universal guidelines to follow.

The U.S. Computer Emergency Readiness Team (CERT) has a long-standing policy that it will disclose technical details of a vulnerability within 45 days of discovery. Other bug hunting teams, such as the Zero Day Initiative, publicly disclose bugs and technical details within four months (120 days) of discovery.

With Project Zero, researchers picked a middle ground, but there is still no overarching guidance for the disclosure of vulnerabilities or bugs. 

What the new Google policy does do, however, is give more consistency, which is a big difference for developers creating the patches, as well as the IT teams that have to take those patches and deploy them within corporate networks, suggested Thomas Hatch, the CTO and co-founder of SaltStack, an automation software firm located in Utah.

“The unwritten rule is that the fix and the disclosure are released at the same time,” Hatch said. “It is impossible to reliably release security issue data to select companies without it leaking out before more companies have the fixes.”

“With that said,” he continued, “it is a fairly standard practice for major vendors to give pre-release vulnerability data to select customers, and it is often negotiated for by large enterprise customers to receive security fixes before public release.”

Offering Bug-Killing Guidance

In some cases, bug disclosures focus too much on vulnerabilities in products and not enough on the customers and their IT teams, which then have to apply these patches, said Joseph Carson, the chief security scientist at Thycotic, a Washington D.C.-based provider of Privileged Access Management (PAM) tools.

Carson suggests that good vulnerability disclosures should focus on:

  • Prioritizing vulnerability notification with the intention of reducing the risks by making the vulnerability public so everyone is aware that a risk exists. This can include applying hardening to reduce the risks or encouraging customers to apply the patch that the vendor sends out.
  • Bug hunters might also consider the difficulty in patching systems and software, and that vulnerabilities might go unpatched for months or years if the patching is difficult.
  • There should also be consideration of actual risk, since not all vulnerabilities are created equal.

“Responsible disclosure is too broad today and needs to really put the customer first,” Carson said. No doubt many companies and cybersecurity experts would agree.