HP Security Research Threat Intelligence Briefing - Episode 9

The use of open source has been a growing trend for some time and it’s a trend that seems to be accelerating. Gartner analysis shows that by 2015, 99% of mission critical applications in the Global 2000 companies will contain open source. There are some major benefits associated with open source that are powering this trend. The most compelling benefit is using open source components to build software greatly decreases the amount of time needed to produce applications.


So what about security? Are there security concerns with using open source software? Absolutely. The very nature of open source is that someone else is writing the code for you. Who is that person? Can you trust them? We are using this code to build mission critical applications, so this question is very important.


In a 2012 study, Aspect Security and Sonatype researched the number of vulnerabilities in common Java applications and how widely they are used. Sonatype is the company behind the Apache Maven repository that helps Java developers with dependency management. Because of Sonatype’s visibility into open source component use, they were able to see if developers are using components with known vulnerabilities. Their conclusion was that more than half of the Global 500 were using open source components with known vulnerabilities. The vast majority of developers use software components to developing applications, so this problem involves nearly any organization  using web applications.


How can we fix the problem? To help customers mitigate the risks associated with open source, we are recommending 5 steps that will work for any size development organization.

 

Step 1 – Identify Your Open Source. If you don’t know what the risks are, it’s difficult to mitigate risks. Poll your development groups asking for a list of open source components. Add a check in your security process that analyzes all of the libraries used in each application. Build a profile on each library covering where it comes from, where to get updates, and how often the open source community releases new versions.


Step 2 – Assess Your Risks. A quick way to assess the vulnerabilities of open source is to query public vulnerability databases and mailing lists. MITRE’s Common Vulnerabilities and Exposures (CVE) database and the Bugtraq mailing list can provide insight into vulnerabilities that have already been identified. If you have a security testing capability, you can test the packages for vulnerabilities that may  not yet have been identified  by the community. Using a combination of automated source code scanning and dynamic analysis is typically the best approach. If you organization does not have this capability, there are services that can help assess the code and provide the results for you.


Once you have discovered vulnerabilities, the obvious question is what to do with them. You have two choices: report them to the open source community or fix the code yourself. If you decide to report the vulnerabilities, it is best to do so responsibly. You are not the only user of the software, so sending an email to the Bugtraq mailing list lets the attackers know about the vulnerability as well. The best plan is to contact the leaders of the open source application and privately provide the details of the vulnerability. Give them time to respond and provide a fix date. If they do not respond or it is taking too long to fix the vulnerability, then consider reporting it.


If you elect to fix the code yourself, keep in mind open source in most cases does not equal free. Most open source projects have a license associated with them that governs the acceptable use of the software. The Gnu Public License (GPL) allows anyone to use the software, but any changes to the software must be released back to open source community. Before editing the code, check the license associated with the project to know what you must do with the edits.


Step 3 – Develop an Acceptable Use Policy. Build a local repository of the approved open source components that developers can use to build software. Developers should get their libraries from the approved repository and not directly from the open source community. It’s important to communicate to the developers why the security team is doing this and how they can help keep the applications secure. Provide a process for developers to request new components be added to the approved list.


Step 4 – Develop a Patch Management Plan. During Step 1, you cataloged where updates can be found and how the open source communities communicate feature and security updates. It’s important to monitor these communication channels to know when updates have been released. If a security patch is released, you will have a list of the applications using that component. You can then work with the list (?) to assess the risk and develop a patching process.


Step 5 – Build a Compliance Gate. Before applications are allowed into production, check what components they are using and make sure they are the approved libraries and approved versions. This check should be performed as early in the process as possible to t prevent an insecure (?) application from entering production.

 

Open source is everywhere. Open source components undoubtedly save us time and money, but there are security risks associated with using these libraries. By following these 5 steps, your organization can achieve open source piece of mind.


To learn more on this interesting topic listen to Episode 9 of the HP Threat Intelligence Briefing Podcast, available on the Web and iTunes, and read the companion report for more details.


Until the next time we meet, be vigilant and stay secure.

Eric Friese

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation