Linked by Thom Holwerda on Sat 1st Jun 2013 18:43 UTC
Privacy, Security, Encryption Google is changing its disclosure policy for zero-day exploits - both in their own software as in that of others - from 60 days do 7 days. "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. As a result, after 7 days have elapsed without a patch or advisory, we will support researchers making details available so that users can take steps to protect themselves. By holding ourselves to the same standard, we hope to improve both the state of web security and the coordination of vulnerability management." I support this 100%. It will force notoriously slow-responding companies - let's not mention any names - to be quicker about helping their customers. Google often uncovers vulnerabilities in other people's software (e.g. half of patches fixed on some Microsoft 'patch Tuesdays' are uncovered by Google), so this could have a big impact.
Thread beginning with comment 563525
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: Comment by Nelson
by cfgr on Mon 3rd Jun 2013 16:28 UTC in reply to "RE[6]: Comment by Nelson"
cfgr
Member since:
2009-07-18

This sounds like the usual nonsense from someone who doesn't work software industry.

Long processes are in there to stop these sort of mistakes happening in the first place or worse making the situation worse.

Except I do work in the software industry and I've seen both sides. And you sound like you're suffering from a serious tunnel vision, probably because it's always been that way to you and it's become rather hard to think outside your cubicle.

Big companies have these long processes to prevent their army of brainless code monkeys from screwing up because they're too cheap to invest in proper development. So yes, they're entirely to blame when their customers' systems get compromised as a result of those long processes. This is just a way of shifting costs that's rather unique to the software industry.

Like I said, other industries have to do a refund, a replacement or a recall when security issues are discovered, and they manage perfectly fine with their own "long processes to stop these sorts of mistakes from happening".

Edited 2013-06-03 16:29 UTC

Reply Parent Score: 3

RE[8]: Comment by Nelson
by lucas_maximus on Mon 3rd Jun 2013 17:14 in reply to "RE[7]: Comment by Nelson"
lucas_maximus Member since:
2009-08-18

Except I do work in the software industry and I've seen both sides. And you sound like you're suffering from a serious tunnel vision, probably because it's always been that way to you and it's become rather hard to think outside your cubicle.


Sorry but that simply isn't true. Firstly I don't work in a cubicle. Secondly understanding business processes and why they exist rather than demanding a highly unrealistic scenario.

Big companies have these long processes to prevent their army of brainless code monkeys from screwing up because they're too cheap to invest in proper development. So yes, they're entirely to blame when their customers' systems get compromised as a result of those long processes. This is just a way of shifting costs that's rather unique to the software industry.


Again you are over-simplifying the situation. Defects are found in even the most tested application frameworks. In fact pretty much every software testing book admits that anything beyond "hello world" examples are likely to have flaws.

Also not all software devs are created equal, processes have to be realistic and have to take this fact into account. Again what you are suggesting is highly unrealistic.

This all happens because someone made a cock-up earlier this is why they exist (and btw it happens whatever the ability of the developer, people are human).

e.g. I spent 3 days negotiating with a dev that was external to my department that I wanted him to setup to separate database instances one for each test environment ... it should be bloody obvious.

Why do you think this is a bad thing? These processes also exist in pretty much every other industry as well.

Like I said, other industries have to do a refund, a replacement or a recall when security issues are discovered, and they manage perfectly fine with their own "long processes to stop these sorts of mistakes from happening".


Because a lot of other industries don't do anything nearly as complex as software and guess what they have rigorous QA processes before anything goes into production as well, just like the software industry.

What you are asking for is highly unrealistic, especially taking into account that the industry is fairly young and misunderstood compared to other industries e.g. manufacturing which is a couple of hundred years old.

At the end of the day, software isn't a physical object and it shouldn't be treated like one.

Reply Parent Score: 2