How to Detect and Enforce Open Source Licenses

Author, Ilkka Turunen

I received this question from a client today:

Right now we are using Nexus OSS. We are considering upgrading to Nexus Pro for two reasons:

  • We need to control licences of our dependencies – with Maven it’s too easy to add dependencies
  • We need to track updates of our dependencies

Nexus Repository Health Check seems like good solution, but I am not sure how to use it.

Our process looks more or less like this:

  • Developer commits code to Gerrit
  • After positive review developer submits change to main branch
  • During release artefacts go to Nexus hosted repository
  • When we need to ship product to customer we get it from Nexus repository

Where Repository Health Check fits into this? As far as I know it can only check proxy repositories. I need to check our software stored in hosted repository.

I would appreciate any clues.

The Answer

You’re correct in your assumption – Repository Health Check is, as the name suggest, a feature to track the security/licensing status of your components in proxy repositories (in Maven these are called ‘artifacts’). It’s intended to be used as a tool to understand what kinds of dependencies you’re ingesting from the outside into your organisation and what types of risks you may be exposed to because of the associated issues. It won’t address individual builds or artifacts.

What you’re looking for is something that integrates as a part of the continuous delivery lifecycle – essentially something to run as a test to verify risk status of the dependencies of individual build results. There are a few ways of doing this in either Nexus Pro+ or Nexus Lifecycle. Both of these tools contain the IQ Server, a server that interacts with Nexus to produce a full bill of materials of all the 3rd party components in your application, and associated licenses and security issues. Not only this, it also allows you to define policies to indicate what kinds of licensing/security/architectural issues constitute risk for your organisation and/or application.

Method 1) Staging repositories and Nexus Pro+

One of the ways to get this kind of information is to use the enhanced staging suite in Nexus Pro+. The Staging suite allows you to model the promotion profile of your application (dev->test->prod), and create temporary repositories for the release artifacts, it is found as a feature in Pro, but the licensing and security health checks can only be enabled in Pro+ / Lifecycle.

The Workflow is pretty similar to yours:

Detect and Enforce Open Source Licenses - 01

Before this, you must define and implement a policy for the application addressing what kinds of licences, security issues and quality attributes are acceptable.

  1. Developer commits code to Gerrit
  2. After positive review developer submits change to main branch
  3. During release artefacts (e.g. jar, war, ear archives) go to Nexus hosted repository with a staging profile
  4. Nexus creates a temporary staging repository. A licensing / security policy check is executed against the applications security / licensing policy
  5. Policy check results and a report are visible with the staging repository. If successful, you can release the artifacts to the designated Releases repository
  6. When we need to ship product to customer we get it from Nexus repository

Basically, you can execute this manual review step as a part of the staging step, and even define multiple steps for the staging repositories. See how it looks like in the screenshots below:

Detect and Enforce Open Source Licenses - 02

Nexus Pro+ : Staging includes a policy check via the IQ Server

Detect and Enforce Open Source Licenses - 03

Method 2) Nexus Lifecycle and Nexus Pro+

In Nexus Pro+, the check with the IQ server can only be executed via invoking a staging repository. The Nexus Lifecycle and Pro+ combination adds multiple integration points and application stages. You can, for example enforce certain policies only at certain points in the lifecycle (e.g. dev/stage/prod builds), and you can evaluate components straight from an IDE. With Lifecycle, the check can be performed after every build, as a post-build action in a CI server, like Jenkins, and can even be invoked from a command line.

The workflow would then become:

Detect and Enforce Open Source Licenses - 04

Again, we must define and implement a policy for the application addressing what kinds of licences, security issues and quality attributes are considered risks.

  1. Developer commits code to Gerrit
  2. The review branch is built, a policy check is performed. If there are violations, the build is marked as unstable and a warning is issued.
  3. after positive review developer submits change to main branch
  4. Main branch is built and another policy check is performed. Again, warnings are issued if there are violations
  5. during release artefacts (e.g. jar, war, ear archives) perform build with a deploy to Nexus hosted repository with a staging profile
  6. A final policy check is performed. If there are violations to critical policies, the build is failed since the warnings of the violated policies have been issued before. If there are none, we progress to staging.
  7. Nexus creates a temporary staging repository. A licensing / security policy check is executed against the applications security / licensing policy
  8. Policy check results and a report are visible with the staging repository. If successful, you can release the artifacts to the designated Releases repository
  9. when we need to ship product to customer we get it from Nexus repository. We know all the licences and security issues related to all of our external components in our shipped release and have improved our dev process early on to mind these issues.

Lifecycle also allows continuous monitoring of applications. Even if an application is secure today it doesn’t mean one of it’s components won’t have a security issue discovered in a few months / years time. Lifecycle will continuously monitor the components identified in previous evaluations for any new security issues. You will be notified if new issues are discovered so you can address the issue.

As an added bonus you can also track things like the most riskiest components and applications based on an aggregate sum of policy violations. You can also expose this policy monitoring to an IDE, so that developers can address issues with the dependencies they’ve chosen early on.

Method 3) Nexus Lifecycle

You could also just include lifecycle without the Nexus repository bits. In this case you’d have to design integration points for your own process. Nexus Lifecycle does provide a wide amount of integration and invocation hooks for you to do this. Additionally it comes with a fully featured REST api. Here are some pictures of a few of the most popular integrations to Nexus Lifecycle:

Detect and Enforce Open Source Licenses - 05

Eclipse IDE Plugin – Exposes the full breadth of lifecycle information about your project’s dependencies

Detect and Enforce Open Source Licenses - 06

Jenkins Plugin – allows you to execute a policy check as a post-build action

Detect and Enforce Open Source Licenses - 07

Nexus Lifecycle Dashboard – Showing continuous information about the risks with your components and application

The following two tabs change content below.
Ilkka Turunen is a Solutions Architect at Sonatype. He has worked with companies large and small as a infrastructure consultant and as a developer. Now he aims to show how the Nexus products can benefit teams large and small. He's based in London, UK and can best be found in a coffee shop near the silicon roundabout.
Authors

Related posts

*

Top