Evaluate Open Source Components Before Use: Open Source Development Tip #5


October 31, 2011 By Terry Bernstein

We’ve been publishing a series of tips on managing open source development to maximize benefits and minimize the risks. In case you missed them, you can find the other posts in the series here and a summary of the entire set of tips here. In today’s post, we continue with a tip on choosing open source components to ensure quality and avoid unnecessary license or security risk.

5.  Evaluate open source components before using them in development

There are over 30,000 unique open source components available in the Central Repository to choose from. More often than not you’ll have multiple choices for any given need, making it hard to choose. Here are a few things to consider when evaluating components.

  • Determine if the component meets your requirements for quality, security and licensing. You’ll want to be sure that candidates are appropriately licensed for your application and are free of known security vulnerabilities.
    License information is sometimes included in the project POM, but we’ve found that this field is often blank or does not match the licensing embedded in the source files.  If you want to be sure about licensing, you need to look at each source file in the project, including all dependencies. 
    You can find security information in a number of free online sites, including cve.mitre.org and osvdb.org.  Unfortunately these resources don’t utilize the standard Maven coordinates (GAV) and so can be difficult to search for Java components. 
  • Typical dependency tree for an open source project

    Problematic open source components may be hidden deep within the dependency tree

    Analyze the component’s dependencies to discover hidden security or license issues. For each open source component you include, there are often dozens of other components it depends upon.  Any of these included components may have a hidden security risk or be licensed inappropriately for your application.  The figure provides an example of this situation.  The complexity of Java dependencies make it difficult to know what your applications are truly made of without using automated tools.

  • Ensure you have a trusted source for each component, such as the Central Repository. You’ve picked the components for your application and verified that they meet your quality, security and licensing needs.  Now you need to download the components from a trusted source to ensure what you download hasn’t been modified maliciously.  You’ll want to choose a source, like the Central Repository, that includes a PGP signature for ensuring the integrity and authenticity of components.  You can read more about Central’s use of PGP signatures here.

Following these guidelines will help you choose better components and avoid risk.   This work is not always easy, but it’s important when you’re building critical apps. We created Sonatype Insight to help you perform these tasks faster and more efficiently. Insight provides the component information you need in your existing development tools.