Open Source ROI with Less Risk
Published: September 19, 2011 13:54
It's a scenario with which many Java developers are all too familiar - and one which many fear. You log on to the network or arrive at the office to discover your Chief Security or Compliance Officer, Application Manager or even a VP of Sales and Marketing in a state of panic. A commonly used open source component has a serious security vulnerability that may expose your client-facing applications to attack. Even worse, the flaw was identified a few weeks ago, but your organization has just heard about it.
The questions and accusations fly: "Why are we using open source components for our critical business applications?!" "Why don't we just rip out this component and replace it with something more secure?" "Do you have any idea what will happen if people discover that our applications have a security flaw?!" "This could negatively impact revenue and our reputation!" And, of course, "What are you going to do to fix this - and ensure it never happens again?!"
How would you answer those questions? What would you be able to do in this situation? If you don't have immediate answers, or an established action plan, you are not alone. It's likely that you would have no easy way of knowing exactly where you have used that particular flawed software component during application development. And once you figure out which applications are using it, you'll have to re-create the development environment, find or write a new version of the component that is more secure, and then build, test and deploy the new version of the application - all of which could take weeks.
To avoid this scenario altogether, application developers need new ways to mitigate the risks of open source without disrupting current development processes. Thankfully, there are specific strategies and new tools available that can help Java developers leverage open source while establishing a more aware, less risky and more robust supply chain. But before we discuss those, let's take a moment to examine open source usage and its associated challenges.
The Rise and Risks of Open Source
Gartner estimates that by 2013, 90 percent of Global 2000 enterprises will include open source software (OSS) as business critical elements of their IT portfolios - and by 2016, that number will increase to 99 percent. It makes sense that open source use is on the rise. Java developers already know that open source offers unmatched flexibility, the power to control and easily modify code and optimize performance. The bottom line: using open source components for software development improves an organization's ability to deliver higher quality software faster at lower cost. However, most Java developers have limited ability to govern the selection, management and distribution of open source components, which can expose your organization to unforeseen technical and compliance risks, including potentially significant threats to software quality, stability, performance, security and intellectual property.
The Central Repository, the industry's leading repository for all major OSS projects, contains more than 300,000 Java artifacts and is accessed by developers nearly four billion times a year - making it one of the most visited sites on the Web today. As stewards of the Central Repository, Sonatype can access, mine and share insight on open source component usage of more than 40,000 software development organizations. We've discovered that many developers are downloading open source components without any reliable way to monitor or control usage, which can introduce significant security threats and licensing risks that can derail development processes and quickly undermine quality production values. In a 2011 Sonatype survey of 1,600 software developers, team leads and architects, 87 percent of respondents stated open source component use is ungoverned within their organization's development process. There are better ways to use open source components without exposing your organization to so much risk.
Mitigaging Risk Across the Application Lifecycle
To manage the use and risks of open source throughout the application development lifecycle, organizations must implement corporate standards for open source-based development. And Java developers need specific tools to manage risk and maximize business value of open-source components. There are tools available now that can help you maximize the ROI and minimize the risk of open source as you design, develop, build, test and move applications into production.
Choose the Best Components
First and foremost, you need a better way to select components to ensure that only the highest quality components are used in your builds. Obviously, with more than 300,000 components available in the Central Repository, it is difficult to ensure usage of the highest quality components, particularly as components are continually being updated. Of 12,389 open source artifacts updated in 2010, 63 percent were updated two or more times and 30 percent were updated four or more times. Fifty-eight percent of respondents to Sonatype's Software Development Infrastructure survey said that they search the web to find out about component changes and 28 percent said there is just no reliable way to find this information. However, there are tools designed to improve open source component quality from the start by helping you choose the best components from within the IDE. You can even search for and find components by category, license, quality and security information as well as receive alerts regarding component updates to ensure flawed components are not accidentally included in your applications.
Identify Security Vulnerabilities
It's not uncommon for vulnerabilities to be discovered in popular components. Even when security warnings are posted and easily accessible, they are often overlooked. In March 2009, the United States Computer Emergency Readiness Team and the National Institute of Standards and Technology (US-CERT/NIST) issued a warning that the Legion of the Bouncy Castle Java Cryptography API component was extremely vulnerable to remote attacks. In January 2011, almost two years later, 1,651 different organizations downloaded the vulnerable version of Bouncy Castle from the Central Repository within a single month. In January 2010, the US-CERT/NIST posted an alert via their National Vulnerability Database that Jetty had a critical security flaw, which might allow attackers to modify a window's title, execute arbitrary comments or overwrite files and allow unauthorized disclosure of information. Regardless of the warning, in December of 2010, nearly a year later, approximately 11,000 different organizations downloaded the vulnerable version of Jetty from the Central Repository in a single month.
You can do more than simply search the Web or rely on word-of-mouth to find out about security flaws. In fact, it's possible to proactively manage open source component usage throughout the software design and development process. Look for tools that allow you to see quality, security and license details about components from within your development environment during the design phase and that will alert you to security vulnerabilities and catch flawed components during development, production and even after the application goes live.
Streamline Dependency Management
Using open source components makes it easy to build applications quickly. But for each component you include, there are often tens of other components it depends on in the application. Dependency management can quickly become a costly and time-consuming manual process as typical applications are comprised of dozens or even hundreds of open source components, and each of these in turn depends on additional components. Established open source usage controls and dependency management can help you minimize the quality, security and licensing problems that can result from the ungoverned use of open source software components.
To further streamline dependency management, implement tools that proactively monitor the entire dependency tree, including transitive dependencies (components that rely on other components). They can help you identify exactly which components are used in your applications by scanning complied applications and generating reports of the full dependency tree. You'll be able to easily identify components with known vulnerabilities, see the license types of all components and quickly address components with quality issues whether they are in the first level or deep within your dependency trees. Look for tools with customizable dashboards and automated alerts that will notify you of significant events, such as when a new vulnerability is discovered in a component on which your applications depend.
Address Licensing Issues
Java component-based development introduces unique licensing issues that must be addressed in order to avoid compliance issues that can result in legal and financial penalties. However, as many project owners do not submit correct licensing information to the Central Repository, it is often difficult to determine component licensing terms. And, due to multiple dependencies inherent to Java development, the components explicitly included in your application often rely on tens of additional components for which you need to address licensing obligations. It is critical to implement and follow licensing policies to ensure that you only include components with license obligations that your enterprise is willing to meet. You can also integrate solutions that improve compliance by identifying component licenses and ensure that unwanted licenses don't make it into your applications during development. Select solutions that will scan your existing applications, including all dependencies, to identify problematic licenses.
Step-by-Step Open Source Control
To ensure component integrity throughout the software supply chain and at every stage of the development process, look for integrated tools that provide insight across each step of the application development lifecycle. There are comprehensive solutions available that will help you manage open source usage in an efficient, non-invasive manner without disrupting your current processes. You want solutions that will provide actionable intelligence during each of the following phases of development:
Improve your initial component search and discovery capabilities with tools that identify components by category, license, quality and security attributes. Ideally, you want tools that allow you to see quality, security and license details about each component from within your development environment.
Implement solutions that notify you of security and licensing issues during development and provide assistance in managing multiple versions of components. Eliminate guesswork that can undermine development with tools that enhance visibility by providing detailed information that will assist you in making upgrade decisions as well as resolving potential license compatibility issues.
Select solutions that allow you to drill down and combine component data so that you can monitor and manage open source consumption as you build applications. You should be able to quickly identify quality, security and licensing criteria and use this information as build promotion criteria. Appropriate tools will show you how many and which versions of each component that you've downloaded, point out exactly where you've used it during your build process to help you manage dependencies and alert you to known security vulnerabilities as you build applications.
Look for solutions that allow you to use quality, license and security information as part of your pass/fail criteria as you build and test new applications. There are also tools available that generate application bills of materials during testing, including the full dependency tree to help you avoid known security vulnerabilities and unwanted licenses.
Eliminate error-prone and expensive manual production processes with automated tools that scan your complied applications and generate reports across your complete dependency tree. You'll want to see components with known vulnerabilities or any quality issues along with the license types of all components. The tools you select should also address any newly discovered security flaws in deployed applications.
With better open source policies and integrated management tools, you can manage the risks of open source and still derive the benefits throughout your development processes. Best of all, you can stop worrying about being blindsided by business colleagues should a security flaw or licensing issue be identified in a component you've included in an application. Should the scenario we described at the onset of this article arise, you'll be prepared to answer questions and address concerns immediately. Instead of scrambling for information, you'll be able to generate a report that tells you exactly where the questionable component is being used and recreate your development environment with ease. You'll just need to pull down a new release of the component that has a fix for the security vulnerability and build, test and deploy your new application in hours instead of weeks.
- Driver, Mark. "What Every IT Practitioner Needs to Know About Open Source." Gartner Group. (October 2010).
- Sonatype Software Development Infrastructure Survey. (January 2011).
- 2010 Central Repository Usage Data. Sonatype Inc. (January 2011).
- Vulnerability Summary for CVE-2007-6721. National Vulnerability Database Version 2.2 Sponsored by DHS National Cyber Security Division. (January 20, 2011).
- Vulnerability Summary for CVE-2009-4611. National Vulnerability Database Version 2.2 Sponsored by DHS National Cyber Security Division. (January 14, 2010).