April 2014
Open Source Quality Challenge Redux (9 April 2014)
Heartbleed: Don't Panic (11 April 2014)
Doing Crypto (22 April 2014)
What Does "Network Neutrality" Mean? (29 April 2014)

Open Source Quality Challenge Redux

9 April 2014

I don’t have time to do a long blog post on Heartbleed, the new flaw in OpenSSL, but there’s one notion going around that needs to be squashed. Specifically, some people are claiming that open source software is inherently more secure:

Because so many people are working on the software, that makes it so it’s less susceptible to problems. For security it’s more important in many ways, because often security is really hard to implement correctly. By having an open source movement around cryptography and SSL, people were able to ensure a lot of basic errors wouldn’t creep into the products.
Not so. What matters is that people really look, and not just with their eyes, but with a variety of automated static and dynamic analysis tools.

Secure systems require more than that, though. They require a careful design process, careful coding, and careful review and testing. All of these need to be done by people who know how to build secure systems, and not just write code. Secure programming is different and harder; most programmers, however brilliant they may be, have never been taught security. And again, it’s not just programming and it’s not just debugging; design—humble design—matters a great deal.

I wrote about this problem in the open source community five years ago. I haven’t seen nearly enough change. We need formal, structured processes, starting at the very beginning, before we’ll see dramatic improvement.

Tags: security
https://www.cs.columbia.edu/~smb/blog/2014-04/2014-04-09.html