Managing Java Dependencies with Nexus Lifecycle

James Nicholson - Featured Image

James Nicholson - Featured Image

A typical Java application can have hundreds of external dependencies that include proprietary libraries and others from many different sources. Tools such as Maven, make adding and managing these dependencies easy, but by themselves they aren’t very picky about what gets included in a project build.

Developers and testers who are focused on rapid delivery of quality software may not have enough time to vet the libraries they are including in their products. Since those libraries can bring in dependencies of their own, it can be difficult to know the exact contents of an application. The results can be messy software products that include libraries with different licensing models, multiple versions of the same library, and libraries with known security and functionality issues.

Policy Based Dependency Management

Sonatype, the developers behind the Nexus Repository Manager, have created a tool for implementing policy-based dependency management. Nexus IQ is the server component in three of their offerings: Nexus Auditor, Nexus Lifecycle and  Nexus Firewall.

Nexus IQ scans project dependencies and Maven repositories, checking for criteria such as license type, reported security issues, age, and popularity. When integrated into a Nexus-managed repository, IQ can then either warn developers of a policy violation or block a build entirely; with the Nexus Firewall option, offending libraries can be quarantined for review, and then black-listed or white-listed based on your choice.

bp_main_screen.png

LEARN MORE ABOUT NEXUS WITH ATLASSIAN!

First Steps

The first thing you’ll do after installing Nexus IQ is define your organization and applications. These are organized as a hierarchy in the IQ interface. Policies can be associated with any level in the hierarchy, so you might have some that apply across your entire company, others for specific departments, divisions/groups, and others for individual applications. Once you’ve done this, you can start creating policies from scratch or import a set of sample policies for simple setup.

Every time you (or your build toolchain) invoke Nexus IQ to scan a product, you provide the server with the name of the application and a phase. Phases track the lifecycle of your software product from development through production. When you determine how to enforce a policy, you set up rules that correspond to the phase that is being scanned.

For example, you might have a policy that flags any dependency that’s gone more than 10 years since its last update, and rules that allow that dependency during development, issue warnings during builds, or stop the build entirely if the dependency is still present at the release phase. Whenever a rule is triggered, Nexus IQ can email specific users with details of the policy violation.

Capture 2016-05-02 at 14.40.31.png

The central concept behind Nexus IQ is the scan. Scanning is a distributed function where data is collected from a build, then uploaded to the IQ Server. The server then checks the information against the policies that you define and then posts the results of the scan.

Managing through Automated Policies

Policies can be build around criteria, such as known security issues, the type of license that the library uses, the age of the library, and how frequently a library is used. Criteria based on license type can be organized into threat groups, allowing any of several values to be the basis for a single condition. Nexus IQ currently can identify over distinct 100 license types.

bp_policy_constraints.png

Nexus IQ offers a variety of interface points where it can be used within a build toolchain. At the most basic level, Nexus Auditor provides a command line tool that will scan applications.  You can also upload .jar and .war files for scanning.

Nexus Lifecycle

Nexus Lifecycle offers a large selection of interface points to incorporate scanning into your development process. With this option, Nexus IQ scanning can be done as a Maven task, a build step as part of your CI process (plugins are available for Bamboo and Jenkins) or as part of a Sonarqube code quality analysis. Plugins for IDEs like Eclipse and IntelliJ, allow developers to initiate scans and see the results directly; visual editing tools provided by the plugins, make resolving policy violations very easy.

bp_nexus_eclipse.png

Nexus IQ provides an interface to Nexus Repository Manager, allowing entire Maven repositories to be scanned through a licensing option called Nexus Firewall. Using this feature, it’s possible to block violating dependencies at the repository level, as well as get a report on policy issues within the repository contents.

bg_nexus_integration.png

You can also waive policies for individual libraries if you wish.

waiver.png

Bamboo Integration

Nexus Lifecycle includes a plugin for Bamboo CI servers. It provides a build task that integrates scanning into a build plan. You can configure the task to specify the application and phase that categorize the scan. A summary of the scan is embedded in Bamboo’s build results page, with links to the full report on the Nexus IQ server. Builds can be configured to fail if policy thresholds are exceeded.

Capture 2016-05-02 at 14.43.38.png

Nexus Firewall

Nexus Firewall provides a valuable tool for insuring the quality of software products, and enables product managers and architects to establish and enforce policies that protect their customers. Nexus Lifecycle gives developers the tools they need to know exactly what goes into their applications at build time, and respond to quality issues. For those organizations working in Java, Node.js and .NET, these are valuable tools. Forthcoming releases will bring this same functionality to ruby and python package archives, and to rpm repositories.

The following two tabs change content below.
I've been working in Software Engineering since 1982. I became interested in development tools when I was working at AT&T Labs in the mid 1990's. I've been focusing on what's now called "devops" since about 2006, because back then nobody else wanted to wrestle with Subversion or install Confluence. I joined Addteq in April of this year after taking a year's sabbatical. I live in Central NJ with my family in a very small apartment that is ruled by a cat.

Latest posts by James Nicholson (see all)

Authors

Related posts

*

Top