Enterprises are increasingly using open source code in the development of internal and external applications -- and for good reason. Using free, prebuilt components rather than writing custom code greatly reduces application development time and improves the chances of making that all-important launch date deadline. When building an application, development teams can easily use a hundred or more different open source libraries, frameworks and tools, along with countless code snippets copied off the Internet.
However, open source code -- even the most widely recognized codebases -- comes with risk. There is no guarantee that open source code is bug free, or even that it was developed with the open source code management processes that are necessary to make code viable for use in enterprise applications. Even an open source project with an active user community can contain vulnerabilities, both old and newly discovered. The open source Ruby on Rails Web application framework, for example, has already been hit by several security vulnerabilities this year, putting an estimated 200,000-plus sites at risk of attacks that could lead to remote code execution. Even worse, the bugs were introduced back in 2007, meaning they are present in all versions of the framework released during a six-year period.
In this tip, we'll examine the extent to which open source code use can put enterprise applications at risk, and ways in which open source code management techniques can reduce those risks.
Open source code and vulnerable components
Some may believe the risks posed by the use of open source code in enterprise applications are limited because in many cases open source code use is limited to specific application components. However, components of an application almost always run with the full privilege of the application, so flaws in any single component should be taken seriously.
The vulnerabilities in any code can range from trivial to severe and can be easy or difficult to exploit, but the risk of a vulnerability being actively exploited increases dramatically when it occurs in a commonly used framework, library or component. Today's freely available hacking toolkits are quickly updated to add any such newly discovered vulnerability to their automated scanners, so any application using the flawed code can -- and will -- be quickly found and exploited, not only by sophisticated hackers, but also by any novice attacker who downloads an automated attack tool.
This problem of vulnerable components being incorporated into new applications has become so acute that it appears in the latest OWASP Top 10 list of application vulnerabilities. In previous versions of the OWASP list, it was included under the more generic entry of "Security Misconfiguration," but now it appears as a separate entry at No. 9: "Using Components with Known Vulnerabilities."
As an example of the problem, OWASP cited two vulnerable components that were downloaded 22 million times in 2011. The first involved an Apache CXF authentication bypass: The Apache CXF framework failed to provide an identity token, which allowed attackers to invoke any Web service with full permission. The second, an abuse of the Expression Language implementation in Spring, an open source Java framework, allowed attackers to execute arbitrary code, effectively taking over the server. The takeaway? Any enterprise application that made use of these flawed frameworks was likely a sitting duck for attackers.
Software security through open source code management
The benefits of making use of open source code will nearly always outweigh the time and resources required to develop an application from scratch, but on the flip side, enterprises must still put a process in place to ensure all third-party code is kept up to date. Most development teams won't even know the origins of some code, let alone if it's an up-to-date version.
Unfortunately, not all open source projects use an understandable version-numbering system, and vulnerability reports don't always specify exactly which versions of a component are vulnerable. Thankfully, sites like CVE and NVD are making it easier to search and find this information.
To improve the management of open source code, a development team must first create and maintain an up-to-date list of all third-party code in use, including all dependencies and sources. For each source, designate a point person who tracks any mailing lists, news and updates. This should not be just a passive activity; not all new vulnerabilities are reported to a central clearinghouse, so public security mailing lists need to be monitored as well. Some teams may find they need to reduce the number of different code sources they use in order to manage them effectively, and there should certainly be a policy in place to govern code use, such as a business case, risk assessment and acceptable licenses.
From the editors: Open source security tools
While open source code can introduce risk in an enterprise setting, open source security tools can help mitigate risks and reduce expenditures on costly tools from vendors. Keith Barker, CISSP and trainer for CBT Nuggets, shows off these great tools every month in a SearchSecurity screencast. Past entries include tutorials on OWASP's Zed Attack Proxy, Wireshark and more.
If an application is using flawed code, first check if it uses the part of the code with the vulnerability and then evaluate whether it could create a risk that needs mitigating. Be aware that many open source projects do not issue patches; instead they tend to just release a new version that fixes the problem. An emergency response plan should be put in place to deal with critical releases, as any application sitting on the Internet will be subject to intense scrutiny and may need a rapid response to prevent an attacker from successfully exploiting a vulnerability.
Enterprise developers that utilize open source libraries should be aware of the risk that open source code poses. Even though such code can significantly reduce software development time, its use can unnecessarily introduce vulnerabilities into enterprise applications, increasing an organization's risk posture and ultimately requiring more time later to remediate. Taking the precautions outlined above will enable enterprises to safely make use of open source libraries and frameworks without exposing applications -- and the organization as a whole -- to unnecessary risk.
About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 15 years of experience in the IT industry and another 16 years of experience in finance. He is founder and managing director of Cobweb Applications Ltd., a consultancy that helps companies secure their networks and websites, and also helps them achieve ISO 27001 certification. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Michael is also a Microsoft Certified Database Administrator and a Microsoft Certified Professional.