When we published our executive brief on security, a few of you immediately reacted wondering if we were calling open source software (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 not paying any attention to a constant stream of critical security updates. As a result, these organizations are exposed to security flaws already 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 security projects, you should evaluate a project not by the number of vulnerabilities you identify with a tool like Sonatype Nexus Repository 2.0, but by the process a project uses for addressing security risks.
Just because a project has many 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 high on the list of projects with known vulnerabilities. Does this mean Tomcat is insecure? No, 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 regularly produces detailed reports that identify how specific commits relate to specific vulnerabilities. Yes, there are many 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 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 exotic AJP vulnerability. If you don't pay attention, all 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 lead to 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 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 take application security seriously, you can take a first step by scanning your dependencies with the Sonatype Nexus Repository 2.0 Repository Health Check.
Tim is a Software Architect with experience in all aspects of software development from project inception to developing scaleable 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 ...
Explore All Posts by Tim OBrienTags
Discover a Better Way to SCA
Forrester evaluated 10 SCA providers and recognized Sonatype with the highest possible scores. Learn why Sonatype was named a leader in Forrester Wave™ for SCA.