Are open-source projects the pathway to better security?

The security of open source software came under scrutiny in the wake of Heartbleed. After all, the defect sat in the code, unnoticed, for roughly two years. Then, as the sun finally set on support for Windows XP, an emergency patch was issued the following week.

The two events provided a contrast between the security of open-source software (OSS) and proprietary packages. Raf Los, James Jardine, and I explored the concept of which is more secure during a Down the Rabbithole Security Newscast last month (the segment starts at 7:30).

Do you trust the security of open-source software?

A common challenge to the security of open-source software is the ability of teams to focus on writing and testing the code. Counter this with organizations that dedicate entire teams solely to testing and improving the quality of the product.

As James pointed out in our discussion, the difference is often the passion. OSS projects appeal to the craft of solving a problem. It provides an opportunity to contribute, to collaborate, to improve.

Perhaps both arguments make sense. What does the evidence suggest?

Coverity weighs in with evidence

According to a recent report from Coverity, open-source projects are more secure.

In 2006, the Coverity Scan service was initiated with the U.S. Department of Homeland Security as a public-private sector research project, focused on open source software quality and security. Coverity now manages the project, providing its development testing technology as a free service to the open source community to help them build quality and security into their software development process.

The results of the Coverity Scan focus on defect density — where a score of 1.0 (per 1000 lines of code) is considered the benchmark for quality. The concept of quality is what is used to determine the security.

Coverity’s analysis found an average defect density of .59 for open source C/C++ projects that leverage the Scan service, compared to an average defect density of .72 for proprietary C/C++ code developed for enterprise projects. In 2013, code quality of open source projects using the Scan service surpassed that of proprietary projects at all code base sizes, which further highlights the open source community’s strong commitment to development testing.

The report provides more detail on the different programming languages and packages based on the scans of over 1500 projects comprising several hundred million lines of code. They provide the scanning service at no charge for open-source projects; this presents an opportunity to get more detail in future reports and improve more projects.

The question we need to ask: is the quality of current software efforts something we should accept?

When it comes to breach, the reality is “when, not if” (read more on the detriment of our bias for breach prevention). When it comes to code, the reality is defects exist.

At what point do we decide to actively test and improve our methods?

Not just for the development — and secure development — but for the selection, testing, and improvement of the software packages we rely on more and more.

With the continued attention on the importance of our software, the actions we take help guide the security implications of the future.

Instead of asking whether open-source is more security than proprietary, the better consideration is how to implement and influence change in the software development industry.

Some suggestions for the path forward

Here are a few thoughts on how to influence and advance positive change:

• Stipulate defect density tolerance in contracts: Coverity seems to equate quality to security. When is the last time we included a contract provision that the code needed to be below a specific defect density? Keep in mind that what a code scanner looks for and what constitutes a defect shifts over time, so this is a nuanced approach that requires more discussion.
• Use evidence-driven approaches: measure — and reward — development based on defect density and other measurements; this also means better training and knowledge transfer between teams to improve quality is required
• Improve communication to increase transparency: regardless of the style of project, we all benefit when we take friction out of communication and adopt more transparency in our approaches. This is an opportunity to share insights for improvement, especially when it comes to security.

What do you think? Leave a comment and share your thoughts with me (@catalyst) and others on twitter.