The Google Online Security Blog has posted an interesting update in response to an IBM 2010 Risk Report.

…we were confused by a claim that 33% of critical and high-risk bugs uncovered in our services in the first half of 2010 were left unpatched. We learned after investigating that the 33% figure referred to a single unpatched vulnerability out of a total of three — and importantly, the one item that was considered unpatched was only mistakenly considered a security vulnerability due to a terminology mix-up. As a result, the true unpatched rate for these high-risk bugs is 0 out of 2, or 0%.

IBM has an updated chart now. Although one can see how Google might take such a sensitive and defensive position when confronted with vulnerability data, their analysis comes across as shockingly one-sided.

They first highlight four “factors working against [vulnerability databases]”. All have a clear tone of “don’t trust those databases” but only one says the vendors have an important role — disclosure in consistent formats. The finger-pointing then goes a step further with two suggestions:

To make these databases more useful for the industry and less likely to spread misinformation, we feel there must be more frequent collaboration between vendors and compilers. As a first step, database compilers should reach out to vendors they plan to cover in order to devise a sustainable solution for both parties that will allow for a more consistent flow of information. Another big improvement would be increased transparency on the part of the compilers — for example, the inclusion of more hard data, the methodology behind the data gathering, and caveat language acknowledging the limitations of the presented data.

I think calling the report misinformation is a bit harsh. Their post only says databases are not to be trusted because the “compilers” do not reach out and are not transparent enough. That should be a two-way commentary. There is no need to place all blame on database researchers and none on vendors like Google. Google could publish more patch information and transparency with regard to its recorded vulnerabilities. They could lead by example, of course, and fix their their security communication and management issues, especially around consistency. That might be the third, but most important, step to make these databases more useful.