By now, you’ve likely seen Google’s announcement that they now support a seven-day timeline for disclosure of critical vulnerabilities. Our CTO Raimund Genes believes that seven days is pretty aggressive and that rushing patches often leads to painful collateral damage.
I agree that with the current environment many firms would have a hard time understanding the vulnerability, creating a patch and running quality assurance in that seven-day window. Hopefully, someday we will look back and wonder why it took us so long to get to a 24 hour patch cycle. Today, fixes are rarely given the level of resource that a new feature would have. But how do we effect a change here?
I would like to float a proposal to change the social contract. My proposal is simple: when reporting a vulnerability to a vendor, the individual finding the flaw should wait at least until the day after the next Patch Tuesday before releasing their report publicly. There should be a declaration in the initial report indicating the intent to publish based on this protocol. I should add that if there are less than fifteen days to the next Patch Tuesday, one should wait one more cycle. That’s it, clean and simple.
Note that this suggested timeline is a minimum wait period for unilateral action on the part of the reporting party. Discussion and negotiation with the vendor is encouraged. If the vendor fixes it sooner and clears release earlier, then by all means publish. If the vendor asks for more time, it is up to the reporting party to balance the risks to the public and the concerns of the vendor and decide whether to grant the extension or go ahead with publication.
Vendors cover a wide spectrum in terms of responsiveness to reported vulnerabilities. Some are super responsive, others do a good job of emulating /dev/null. My proposal aims to level the playing field. Researchers would have the responsibility to provide notice to the vendor and a reasonable time to repair, this would give them the right to publish on a set timeline. Vendors would have the right to expect advanced notice and the responsibility to fix within the agreed timeline.
One final thought: I used Patch Tuesday because it is well-known and prevalent. If the vendor has an established patch cycle, it would be good form to use their cycle, provided it is reasonable. If the cycle is too long (e.g. updates are released on January 1st every other year), then I suggest falling back to the Patch Tuesday model.
Share this article