Evaluating an Open Source Project's Security

April 10, 2012
By Tim OBrien

Last week, I wrote about how important it is to pay attention to the security of the open source software (OSS) projects you depend on. This isn't just a one-time responsibility when you are trying to choose which component to depend on; this is an ongoing requirement. Even if you use the most secure OSS projects out there, if you don't pay attention to security updates, it's all for nothing. Staying secure requires constant vigilance.

In this post, I'm going to talk about OSS project security. Since we've been paying a lot of attention to OSS security, I wanted to lay out some guidelines for evaluating an OSS project's security. There are many approaches to security from OSS projects: on one end of the spectrum, a one-person OSS project on Github won't have a formal approach to security; on the other end of the spectrum, a project at the center of a billion-dollar commercial ecosystem (like Apache httpd or Tomcat) will have a dedicated security team.

This post focuses on the secure end of the spectrum—projects like Tomcat and Apache httpd with dedicated security teams. Here are some baseline requirements for an OSS security team. If you maintain an open source project and want to let the end-user know you take security seriously, you should consider starting a security team and following the guidelines in this post.

If you are consuming open source, you should look for the following signs that this project has a mature approach to security in place:

• A low-volume general, public announcements list - Every OSS project should have an "announcements" list, which only contains release announcements or critical security announcements, no more, no less. Having a low-volume announcement list and being disciplined about what you send to this list increases the value of having an announcement list. The best case is a project with a separate security announcement list. Users can define filters and flag these messages as important security guides. The worst case is a project with a noisy list, which is a mixture of discussions and announcements. Keep the noise out of security announcements.

• A private security list - If you run an open source project and someone notifies you of a vulnerability, you'll want a private place to discuss the potential impact and any proposed fixes. If your project is especially large (Linux, httpd, Tomcat), you want to limit this list to a few trusted members of the project.

• One or more PGP Keys - This is a critical requirement. If someone identifies a security vulnerability in your software, they need some assurance that the vulnerability report is being delivered to the right people. This is critical, because (as a hypothetical) if I compromise Tomcat, I might also attempt to compromise the accounts of the people who maintain Tomcat. Email is, in general, unencrypted over the public internet. You shouldn't put anything sensitive into a plaintext email that you wouldn't want broadcast to the entire world.

• How to report a vulnerability - Every project has different requirements, but if someone reports a vulnerability in a project like Tomcat, the security team will likely want to know some basic common details: what JVM was being used? What version of Tomcat was vulnerable? Is there any exploit code that can test the vulnerability? Also important: who else is aware of the vulnerability? How long have you known about the vulnerability? Are you aware of any successful attacks using this vulnerability?

• A description of the security process - This is especially important, because security teams are part of an OSS project that is very opaque. While the public has visibility into almost all other aspects of a collaborative open source project, the security team often works in secret to address identified vulnerabilities (possibly for months before they are generally known). To reduce friction between transparency and secrecy, ensure the public is aware of the security process. Consider retroactive transparency for discussions once the exploit has been published.

Here are a few examples of projects with mature security teams:

• SpringSource Security Team - http://www.springsource.com/security
• Apache Security Team - http://www.apache.org/security/ (Focuses mostly on APR and HTTP)
• Apache Tomcat Security Team - http://tomcat.apache.org/security.html
• Apache Struts Security Team - http://struts.apache.org/security.html

These projects have enough developers to have created a critical mass of both end-users and developers. All of these projects also have a strong commercial interest that can sustain continuous investment in a security team. As I've been surveying open source security, I've been impressed at the speed with which most open source projects react to security vulnerabilities. In general, projects attached to a respected forge (like Apache and Eclipse) are associated with a process and procedure to ensure that end-users have an interface to a security team. On the other hand, I see a large list of projects that don't present any interface for security other than a public developer's list.

If we're going to take application security seriously, every open source project should take the time to meet these minimum standards for presenting a secure interface to end-users.

Written by Tim OBrien

Tim is a Software Architect with experience in all aspects of software development from project inception to developing scalable production architectures for large-scale systems during critical, high-risk events such as Black Friday. He has helped many organizations ranging from small startups to Fortune 100 companies take a more strategic approach to adopting and evaluating technology and managing the risks associated with change.