Open source security: Security in process, not code

Yesterday's "big" news was that some major open-source projects have security holes. At least, that's the news that the media reported. Undoubtedly, Microsoft and others will use these results in their competitive documents to suggest that open source is less secure than its proprietary brethren.

This, of course, would be the exact inverse of the lesson to take from the report.

The big news is that we even know. With a proprietary product, no one knows there are gaping security holes...until someone exploits them. Open source makes no attempts to obfuscate its strengths (and weaknesses), letting both the bad guys and the good guys discover the problems, with the latter fixing them more quickly (on average - it depends on the project) than proprietary vendors.

Indeed, of its results Coverity noted:

To know the number of security exposures found within a popular piece of software is unusual, said [Coverity]. Open source projects are different from commercial products in that commercial companies rarely acknowledge security defects in their code or whether they have been dealt with. "Our commercial customers wouldn't like it too much if we aired the number of defects found in their code," said [Coverity], when asked about the results from scans on 400 product lines of the firm's private customers.

Now, never mind this silly distinction between "commercial" and "open source" in the quote. Open source is every bit as commercial as proprietary software.

No, the lesson to take is that customers benefit from an open security process, not a clandestine process that helps no one. We should be grateful when we read that our software has problems. At least we know. That, of course, is the necessary precondition to fixing those problems.