The future of opensource security
The question arose out of the urgency of the heartbleed OpenSSL bug and the hurried round of patching that ensued: what is the future of opensource security management, and what can we learn from this crisis? Shrikanth RP, executive editor for Times India writes:
A recent report by Coverity found out that the quality of open source surpassed proprietary projects with a defect density of 0.59 per thousand lines of code for open source compared to 0.72 for proprietary code scanned. Defect density (defects per 1,000 lines of software code) is a commonly used measurement for software quality. The report mentions that nearly 50,000 defects were fixed in 2013 alone - the largest single number of defects fixed in a single year. More than 11,000 of these defects were fixed by the four largest projects in the service: NetBSD, FreeBSD, LibreOffice and Linux. So, what do these statistics mean for open source security, and how must organizations look at open source security post Heartbleed?Better peer review, more atomic code commits and checks, periodic, 3rd party audits: what should we be doing to improve the quality of our code?
2. "With a million eyes, all bugs are shallow" turns out to be BS when it comes to complex code, which certainly includes infrastructure that implements cryptographic and security protocols.
Bugs in the TFA and TFS at Slashdot/Soylentnews/Pipedot, OK, the crowd can be counted on to point out those.
3. Open source might be even *more* vulnerable than proprietary software to security vulnerabilities, because the source code is so easily obtainable in readable form, no reverse engineering necessary. Just as door locks keep the casual thieves away, "security by obscurity" raises the acquisition costs for potential attackers. This just means that the open source community has to be more vigilant than their closed source counterparts, not less.