Thursday, October 13, 2011

Guidelines for Securing Open Source Software

Our recent security audit of libpurple and related libraries got us thinking about the general problem of open source security auditing, and we wanted to share what we’ve learned. Free and open source software that happens to be community-supported can be challenging from a security perspective. There is a fair amount of recent literature on this topic, and it is debatable whether openly readable source code helps defenders more than it helps attackers.

The key issue is not about source code but the fact that community-based open source software projects often lack the organized resources of their corporate cousins. If large corporate projects choose to prioritize security, they can usually afford to hire experts to do regular security reviews; community projects need to find and coordinate volunteers with this specialized focus. In an environment where developers are stretched thin and often have a wide array of responsibilities, the search for security bugs may be less organized and lag behind. How do we combat this problem? How can we ensure good security in a world where vulnerabilities in important open source software can have disastrous consequences for users all over the world?

These are hard questions without simple answers. Yet although there are weaknesses to free, community-supported open source, there are also strengths: one can take advantage of crowdsourcing, open discussion, and can often give integrated updates with less hassle due to friendlier and sane licensing. In order to take advantage of the strengths while mitigating the weaknesses, we think that there are some design choices that these projects can make to drastically cut down on the amount of effort that will be required to do security auditing. These suggestions are by no means original, but we think are even more important to emphasize within the framework of the community-supported open source.
  • Make the code as simple, modular, and easy to understand as possible. To take advantage of volunteer effort to crowdsource security auditing, the barrier to entry for understanding the code has to be quite low. Modularity in itself helps improve security, but it also helps people take a look at one aspect of the code without having to digest the possibly complicated way that it all hangs together.                 More