Google: Security flaws not fixed in a week should be made public

Google: Security flaws not fixed in a week should be made public

Summary: Google's security engineers approve of researchers publishing details of flaws in the company's products if it does not respond within seven days.


Google is pushing for a new "aggressive" response timeline for security vulnerabilities, where vendors would be given seven days to patch to the flaw, notify the public or disable affected products.

If researchers find a previously unseen critical flaw that is being used in real-world attacks, they will have Google's blessing to publish details about it seven days after alerting the affected vendor.

"Seven days is an aggressive timeline and may be too short for some vendors to update their products, but it should be enough time to publish advice about possible mitigations, such as temporarily disabling a service, restricting access, or contacting the vendor for more information," Google security engineers Chris Evans and Drew Hintz wrote.

Google announced its new recommended "aggressive timeline" on Wednesday, which would slash its current recommended disclosure timeline of 60 days.

The move comes shortly after Google security researcher Tavis Ormandy published details for a zero-day Windows kernel flaw on Full Disclosure that could allow an attacker to gain escalated privileges on a target machine.

At the time Microsoft acknowledged reports of the flaw, but told Computerworld that it had not detected any attacks on its customers using the flaw. There is no patch or workaround for the vulnerability, and Danish security company Secunia has issued a basic advisory for the bug, which is said to affected fully patched Windows 7 x86 Professional, Windows 8, and possibly other versions of the OS.

Google does not say that its new recommendation is in response to that particular flaw, and Evans and Hintz note that its team "recently discovered that attackers are actively targeting a previously unknown and unpatched vulnerability in software belonging to another company".

While a seven-day response deadline may be difficult for some vendors to meet, the Google engineers argue it is a necessary move to respond to the threat of targeted attacks. 

"Often, we find that zero-day vulnerabilities are used to target a limited subset of people. In many cases, this targeting actually makes the attack more serious than a broader attack, and more urgent to resolve quickly. Political activists are frequent targets, and the consequences of being compromised can have real safety implications in parts of the world," Google's security team said. 

"Based on our experience, however, we believe that more urgent action — within seven days — is appropriate for critical vulnerabilities under active exploitation. The reason for this special designation is that each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more computers will be compromised."

Topics: Google, Microsoft, Security

Liam Tung

About Liam Tung

Liam Tung is an Australian business technology journalist living a few too many Swedish miles north of Stockholm for his liking. He gained a bachelors degree in economics and arts (cultural studies) at Sydney's Macquarie University, but hacked (without Norse or malicious code for that matter) his way into a career as an enterprise tech, security and telecommunications journalist with ZDNet Australia. These days Liam is a full time freelance technology journalist who writes for several publications.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • that sounds like something a company with no

    enterprise experience and no complex applications would say so no surprise there. Back in the real world enterprises have other things they're focused on and having a quick fix for a security problem doesn't mean they can test and deploy it asap and making them public increases their risk.
    Johnny Vegas
    • Google has ZERO software quality

      They release updates when the developer claims is ready.
  • Google: Security flaws not fixed in a week should be made public

    "Microsoft acknowledged reports of the flaw, but told Computerworld that it had not detected any attacks on its customers using the flaw"

    So does that mean That Microsoft can take its sweet time to fix the problem?

    So is Microsoft responsible for the damages the flaw may cause if they don't fix it in a timely manner?
    Over and Out
    • There is a HUGE difference between ...

      ... rushing out a (potentially destabilizing) fix because of some arbitrarily imposed deadline and releasing a fix that has been carefully and thoroughly analyzed, implemented, reviewed and tested.

      That said, I do agree with the comment that all zero-day issues should have an information page which outlines the issue, possible mitigations, etc. as soon after disclosure as possible.
      • Oh ... and Larry ...

        ... THIS is why "we can't all just get along".

        Trying to put unnecessary pressure on competitors using back-handed techniques like this does nothing to foster closer, more trustworthy working relationships.

        So much for the "woe is me" rhetoric.
  • Google: Security flaws not fixed in a week should be made public

    Google only wants this if it does not affect their products. Its easier for them to patch because their employees just sit around playing with office toys all day. Microsoft on the other hand has to do rigorous testing of patches against all their products to ensure any changes will not disrupt the work flow of the other products. Google can have their 7 days and have a sloppy product and service but I'd rather stick with the company who does testing and gets the patches right without breaking anything.
    • Microsoft on the other hand has to do rigorous testing

      I'm not convinced...

    • Mr. Davidson, how soon you forget

      Remember security update 2823324, part of Microsoft's security bulletin MS13-036, from the April, 2013, patch Tuesday:

      "Microsoft pulls Patch Tuesday security fix
      April 12, 2013
      "Summary: Microsoft is recommending an update released on Patch Tuesday be uninstalled.

      Can't blame Google for this.
      Rabid Howler Monkey
    • Can't forget XP SP3

      With there intelppm.sys driver that would blue screen on any AMD based system.. Sound like rigorous testing to me..
      Anthony E
    • If they're playing all day

      how do they have time to put out quick patches?
      Michael Alan Goff
  • Cup your ears and listen to the chorus ...

    Microsoft's most strident supporters at ZDNet are howling like a pack of rabid howler monkeys. :)

    P.S. One would also hope that this policy also applies to Google's Open Handset Alliance partners, including the carriers, that are often late with Android security patches.
    Rabid Howler Monkey
  • I would say a 14 day turn around for full disclosure.

    7 day window is too short for some application testing.. Especially if its a multiplatform software.
    Anthony E
    • Disclosure in 14 .... but not FULL

      All you do with full disclosure is release the code to take advantage of the bug. In other words, you give the bad guys more weapons.

      What completely incompetent people forget is that just because a patch is released quickly it doesn't mean that the USERS can actually install the patch right away. The developer is not the only one who must perform a lot of testing before a patch is applied.
  • Seems an abitious target

    Hope it becomes a trend - a real one.
    • I agree

      In these times of cyber wars between World Governments and Terrorists Organizations, ambitious targets for cyber security is a good thing and hopefully it can be met more than not by all players.
  • Google is Right

    Bad Guys don't wait for your slow old fashioned QA processes, why should your customers?

    There are arguments to be made for immediate release, but on balance, I think a modest gap is wise. 7 days is better than 60.

    Initial security fixes should be narrow: stop the hole, publish mitigation strategies. Don't try to slip other updates in at the same time. This reduces the QA risks.

    If your process cannot operate in 7 days, fix it. I admit this may change how things are done: think of how an Android bug fix might require a whole bunch of phone vendors to release new firmware, something they don't seem to want to do. Well, that just shows how wrong the Android firmware distribution strategy is. On the other hand, Linux distros seem to manage a similar problem, mostly because they consider security one of their core purposes.

    Security isn't easy, but it is important.