The OSS projects you depend on take security seriously. Do you?

When we published our executive brief on security a few of you immediately reacted wondering if we were calling OSS insecure, we are not. OSS is both secure and increasingly awesome. What we're trying to call attention to is the disconnect between OSS security and the ways in which it is consumed. It is clear from our survey of the data that many organizations are just not paying any attention to a constant stream of critical security updates. As a result these organizations are exposed to security flaws that have already been addressed by these projects.

Important projects, projects like Apache httpd, Apache Tomcat, JBoss, or Spring all have something in common. Each of these projects has a formal security team and a process for addressing security flaws. The presence of a security team in an OSS project is a signature of how seriously a project takes vulnerabilities. If you are evaluating projects for security, you should evaluate a project not by the number of vulnerabilities you identify with a tool like Nexus 2.0, but on the process a project uses for addressing security risks.

Just because a project has a large number of vulnerabilities doesn't mean this project is insecure. Take, for example, Tomcat.

An Example: Is Tomcat Insecure?

If we were comparing OSS projects on the number of vulnerabilities alone, Tomcat would rank very high on the list of projects with known vulnerabilities. Does this mean Tomcat is insecure? No, on the contrary, the Apache Tomcat project sets the gold standard for how to respond to security issues. They have a dedicated security team that quickly responds to vulnerabilities and they regularly produce detailed reports that identify how specific commits relate to specific vulnerabilities. Yes, there are a high number of vulnerabilities, but you couldn't ask for a better response.

Components like Tomcat, GWT, Spring top the list of security vulnerabilities because these projects are so widely used. No, Tomcat is not insecure, but here's the nuanced point we've been trying to make for a few months. Tomcat is very insecure if you are not paying attention to this constant stream of vulnerabilities and fixes. You can evaluate Tomcat for security, conclude that they take security seriously, install Tomcat 6.0.5, and then stop paying attention to these updates. Several months later you will be vulnerable to the recently identified Hash-based DOS attack and some exotic AJP vulnerability. If you don't pay attention, all of this security effort is for nothing.

Tomcat's Security Depends on Your Paying Attention

The effective security of a project is a function of several factors:

• How widely used is the project? - A larger ecosystem for an OSS project will result in more eyeballs reporting flaws and more interest in quickly addressing vulnerabilities.
• Does the project have a mature security effort? - Going back to a project like Tomcat. Does the project accept vulnerability reports? do they address vulnerabilities on a private list? and how quick are they to fix security bugs?
• Are you paying attention? - If you are not paying attention, a project's investment in security is worthless to you. If you use Tomcat and you don't pay attention to the Tomcat security team your own security will degrade over time. (You might as well just not evaluate security at all.)

If you want to start taking application security seriously, you can take a first step by starting to scan your dependencies with the Nexus 2.0 Repository Health Check.