Repository Management with Nexus

22.4. Governance

22.4.1. Identify Insecure OSS Components In Nexus

The Repository Health Check in Nexus Professional turns your repository manager into the first line of defence against security vulnerabilities. Nexus Professional scans components and finds cached components with known vulnerabilities from the Common Vulnerabilities and Exposures (CVE) database. You can get an immediate view of your exposure from the Repository Health Check summary report with vulnerabilities grouped by severity according to the Common Vulnerability Scoring System (CVSS).

As your developers download components, they may be unwittingly downloading components with critical security vulnerabilities, that might expose your applications to known exploits. According to a joint study by Aspect Security and Sonatype released in 2012, Global 500 corporations downloaded 2.8 million flawed components in one year. Nexus becomes an effective way to discover flawed components in your repositories allowing you to avoid falling victim to known exploits.

figs/web/eval-rhc-overview.png

Figure 22.3. Repository Heath Check Summary


In this example, you will…

  • Start an analysis of all components proxied from the Central Repository
  • Inspect the number of security vulnerabilities found

Let’s get started

  1. Follow the proxying examples in Section 22.3, “The Basics: Proxying And Publishing” to seed the Central proxy repository of your Nexus instance. These examples include several components with security vulnerabilities and license issues as dependencies.
  2. Once your Nexus instance has cached the components, open the Nexus interface, log in as administrator and click on the green Analyze button next to your Central proxy repository
  3. After the completion of the analysis, the button will change into an indicator of the number of security and license issues found
  4. Hover your mouse over the indicator and Nexus will show you a summary report detailing the number and type of security vulnerabilities present in you repository.
  5. Optionally build some of your own applications to get further components proxied and see if additional security issues appear.
figs/web/eval-security.png

Figure 22.4. Security Vulnerability Summary Display From Repository Health Check


Nexus Professional users gain access to further details about all the components with security vulnerabilities including their repository coordinates to uniquely identify the component as well as links to the vulnerability database records for further details.

22.4.2. Track Your Exposure To OSS Licenses

With Open Source Software (OSS) component usage as the de-facto standard for enterprise application development, the importance of tracking and identifying your exposure to OSS licenses is an essential part of the software development lifecycle. Organizations need tools that let them govern, track, and manage the adoption of open source projects and the evaluation of the licenses and obligations, that are part of OSS development and OSS component usage.

With Nexus Professional’s Repository Health Check, your repository becomes more than just a place to store binary components. It becomes a tool to implement policies and govern the open source licenses used in development to create your applications.

In this example, you will…

  • Start an analysis of all components proxied from the Central Repository
  • Inspect the number of license issues found

Let’s get started

  1. Follow the proxying examples in Section 22.3, “The Basics: Proxying And Publishing” to seed the Central proxy repository of your Nexus instance. These examples include several components with security vulnerabilities and license issues as dependencies.
  2. Once your Nexus instance has cached the components, log in to the Nexus interface as administrator and click on the green Analyze button next to your Central proxy repository in the Repositories list
  3. After the completion of the analysis, the button will change into an indicator of the number of security and license issues found
  4. Hover your mouse over the indicator and Nexus will show you a summary report detailing the number and type of license issues of components present in you repository.
  5. Optionally build some of your own applications to get further components proxied and see if additional license issues appear.
figs/web/eval-license.png

Figure 22.5. License Analysis Summary Display From Repository Health Check


Nexus Open Source and the Trial version show the summary information found by the analysis.

Nexus Professional customers can access a detailed report to identify specific components with known security vulnerabilities or unacceptable licenses. The component lists can be sorted by OSS license or security vulnerabilities, and Nexus Professional provides specific information about licenses and security vulnerabilities. A detailed walkthrough of this report is available on the Sonatype website.

figs/web/eval-rhc-detail.png

Figure 22.6. Repository Health Check Details With License Issues List


22.4.3. Component Procurement

Consider the default behaviour of a proxy repository. Any developer can reference any component stored in a remote repository and cause Nexus to retrieve it from the remote repository. Any developer, anywhere in your organization, can add any dependency to your software. This is possible regardless of the license or security issues of that component or any of its dependencies, that are automatically added as well as - so called transitive dependencies..

If you want control over the components used in a proxy repository, the Nexus Procurement feature was designed to give organizations a mechanism to limit the components that are served from Nexus to your users. This valuable governance tool can give you the certainty you need to deliver reliable software.

In this example, you will…

  • Configure access rules for components that can be referenced in this Procured version

Let’s get started

  1. Your evaluation instance of Nexus has been preconfigured with the following steps

    1. A hosted repository named Procured Central has been created
    2. Artifact Procurement was enabled with the Central proxy repository as the source for the procuring into the newly created Procured Central repository
  2. Click on Artifact Procurement in the Enterprise menu in the left hand navigation of the Nexus user interface
  3. Select Procured Central from the list
  4. Define rules for procurement by right clicking on the desired sections of the repository structure including disallowing some components → Read more…
  5. Modify your settings.xml to use the Repository Path of the procured repository in the url section of the mirror element
  6. Try building a Maven project that references one of the disallowed components, after deleting the local Maven repository.
  7. Observe how the procurement rule prevents the build from succeeding, because retrieval of a component is blocked by procurement.