You can't get away from it. Thousands of open source components are being used in every industry, every day, to quickly build and deploy applications. For those not in the security industry, it's hard to keep track of what is being done in this field to manage and monitor open source usage. This article is the first in a series where we will talk about open source in layman terms, identify how prevalent open source is in the modern development environment and how teams are approaching the management of such a multi-headed hydra.
To get started, here are five basic things you should know about open source.
A lot of people shake their head, "No", when they hear this one. In the surveys that we've done, most people estimate that their usage of open source components is about 20% of an application's footprint.
When we run an application health check, jaws usually hit the floor.
Not only are there about four times the amount of components in the application then they thought there were, some of those components have known vulnerabilities that have been fixed for years.
Yes, that's 13 billion with a 'B'. Open source is ubiquitous within the development community. If you don't think your team is using open source as a major aspect of your development strategy, you're just fooling yourself.
Your team is using open source. You can have all your policies in place, you can have all the rules spelled out, but unless you have an automated policy to manage the use of those components, there's no possible way to know what is being used.
In an upcoming survey report, we'll show you statistics that confirm "67% of the developers say their company has no open source security policies in place or the policies that are in place are not enforced."
This might be a little hard to swallow when you think about the past problems with OpenSSL, struts2, and Bouncy Castle, but on a whole, open source components are secure. The teams that built them are constantly updating them and making those updates available. The problem isn't one of bad components, it's one of bad component versions.
In the article, "4 Open Source Components You Need to Update Right Now", Brian Fox makes the case for version control as part of the problem: "The issue is that users don’t respond as quickly to consume the fixes. Given that attackers are notified via the same mechanism that a vulnerability has been found and fixed, they effectively have first mover advantage because it’s generally easier to exploit than it is to update your application framework."
Gary McGraw from Cigital brought this to my attention at the recent RSA Conference in San Francisco. His contention is that you can have two safe components, but in combination an unexpected consequence might lead to a vulnerability. When you think of it, with 13 billion downloads a year, it's virtually impossible to check all dependencies and their relationships unless you have some kind of automated monitoring.
The stats don't lie. Since July 20, 2013, 4076 organizations have downloaded a vulnerable version of struts2 over 179,000 times. That's just one example. There are many more.
We're currently working on an analysis of the top 25 vulnerable component downloads, but you can get ahead of the curve on this one by checking your applications for vulnerable component versions. The four that might surprise you the most are struts2, httpclient 3.x, jetty and Bouncy Castle.
Yes, we know. You'd NEVER knowingly use open source components with a Level 10 vulnerability, but someone is downloading them, someone has used them and unless you are closely monitoring your environment, there's a good chance that some have found a way through your 'golden repository' and are just waiting for the right time to be exploited.
Using manual processes to manage and monitor open source usage in your software development life cycle just doesn't work. With the ubiquity of open source, automation is the only feasible way to have visibility into your components and licensing issues.
What we propose is a three step process.
Identify open source components currently in use within your environment
Target high level (Severity 7 and above) component versions and update them
Use an automation tool to manage and monitor your use of open source components
As stewards of the Central Repository, our objective is to help developers make the right choices, and monitor those choices, through making informed decisions about what they are using to build their software. Look for our upcoming series on the Top 25 Vulnerable Open Source Components and our updated toolset that will help you identify those components within your environment.
First things first: what is currently in your environment??? Don't guess… find out.
