It's a good article. What we have done for LedgerSMB is to try to have a 48 hour immediate response guarantee, a 7 day reproduction guarantee, and a 30 day fix or workaround. Usually things have moved much faster (and unless the problem is complex, we usually have a fix within 7 days).
The big problem we have been facing is that after our initial efforts to secure the application, we have run into fewer and fewer classes of vulnerabilities that we have to worry about and these are more and more complex to exploit. Our new code is verifiably SQL injection free with only a few areas requiring periodic manual review, and SQL injections even if they could occur, would be far more limited in scope than they were in previous versions.
Consequently, it is easy to let things fall through the cracks particularly as security gets very good. We have, truth be told, had problems there.
We periodically review CVE's for related software to see if we missed something that might have otherwise been missed. We have found items that have fallen through the cracks in this way.
But regarding why folks should care, if you look at
"In the case of yesterday's Node.JS release, which did not practice complete disclosure, and did put the fix in a larger patch, this did not prevent interested individuals from finding out the attack, it took me about five minutes to do so, and any serious individual could have done it much faster."
I'd say you're spot on. I'm sure this wouldn't be the last "this is how you should really disclose" posts either. I prefer that approach to just lamenting about how terrible it was and fortunately there are many great examples to draw from.
There have been cases in LedgerSMB where we have had to do something like that. The SQL injection fixes in 1.2.0 were too numerous to backport without extensive beta testing, and the new permissions management system in 1.3.0 could not be backported for similar reasons. In both cases, the same workarounds were suggested.
However, those really should be rare cases.
It is worth noting that while we could not backport our anti-CRSF measures to 1.2, we did provide separate fixes to the most severe CRSF vectors (like those which could lead to account takeover).
The big problem we have been facing is that after our initial efforts to secure the application, we have run into fewer and fewer classes of vulnerabilities that we have to worry about and these are more and more complex to exploit. Our new code is verifiably SQL injection free with only a few areas requiring periodic manual review, and SQL injections even if they could occur, would be far more limited in scope than they were in previous versions.
Consequently, it is easy to let things fall through the cracks particularly as security gets very good. We have, truth be told, had problems there.
We periodically review CVE's for related software to see if we missed something that might have otherwise been missed. We have found items that have fallen through the cracks in this way.
But regarding why folks should care, if you look at
http://secunia.com/advisories/product/11786/?task=advisories
and compare with
http://secunia.com/advisories/product/11926/?task=advisories
Which will you choose for your business?