The future of opensource security

in ask on 2014-06-18 10:14 (#3P3)

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 comments

Welcome Outsiders (Score: 0)

by Anonymous Coward on 2014-06-18 21:10 (#260)

For real. Many projects are still stuck in cabal mode, where the maintainers pay only lip service to community contributions. Often but not exclusively projects doing "open core" models.

When a project is really open to outsiders, it can encourage more eyes who (a) give a damn about the code quality and (b) are empowered to do something about it.

Oh, and document the thing.

Some rather obvious conclusions (Score: 1)

by marqueeblink@pipedot.org on 2014-06-19 00:27 (#261)

1. Monocultures are bad, whether it's proprietary software with IE 6, or open source with OpenSSL. When one software product has 90 percent market share year after year, be afraid.

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.