Available in Nexus Repository OSS and Nexus Repository Pro
Repository Health Check is a feature of Nexus Repository Manager Pro and Nexus Repository Manager OSS that integrates data from the Sonatype Data Services.
Repository Health Check provides access to a limited subset of the available data right in your repository manager. The Sonatype Data Services expose known data about the components in proxy repositories, including license information, security vulnerability data, and other statistics like relative usage popularity and age. Repository Health Check allows you to examine a high level overview of the available security and license data of components in an analyzed repository.
When enabled, Repository Health Check analyzes all components found in a proxy repository regardless of the format. maven2 proxy repositories need to have a Version policy of type Release configured to be analyzed. nuget proxy repositories support Repository Health Check and component identification. Some license or security data is provided as well. Support for npm repositories has similar restrictions.
Availability of component metadata varies depending on the format and is constantly improved via updates to the Sonatype Data Services.
Repository Health Check can be setup for any repository, as long as the following apply:
If the repository Status is Offline you can run the health check analysis, however it will not complete until the repository is Online.
Repository Health Check for a single repository can be enabled in one of two ways. The quickest way is to click the Analyze button available in the list of repositories. After pressing this button, you will be prompted to either analyze all or only the selected repository and to agree to the license terms at the first activation of Repository Health Check.
Alternatively, you can select the repository in the list of repositories and then click the Enable HealthCheck button in the repository configuration view.
Once enabled, a task that performs the analysis is created and initialized. This task uses the identifier of the repository and the prefix Health Check: as a name and is automatically configured to run regularly. The recurrence frequency can be changed in the scheduled task administration described in Section 4.2.7, “Configuring and Executing Tasks”. New component data is supplied by the Sonatype Data Services to Nexus Repository Manager daily.
Disabling health check for a specific repository removes this scheduled task automatically. You can also remove these tasks manually. Adding them, however, cannot be done through the tasks administration and must be done as described previously.
After a successful analysis and refresh, the Health check column in the list of repositories will display security and license issue counts for the repository. An example is displayed in Figure 8.1, “The Repositories List with Health Check Result Count”.
Hovering your mouse pointer over that value will display the summary data in a pop-up window. A sample window is displayed in Figure 8.2, “A Result Summary for a Repository Health Check”.
At the bottom of the summary, you can click the link View Detailed Report to access a more detailed report. This report is only available in Nexus Repository Manager Pro. More details are provided in Section 8.3, “Accessing the Detailed Repository Health Check Report”.
Rather than enabling and disabling health check for each repository, you can enable Repository Health Check globally. This can be achieved by creating and configuring a new capability called Health Check: Configuration. General details about managing capabilities can be found in Section 4.2.2, “Accessing and Configuring Capabilities”.
The Health Check: Configuration capability can be enabled and disabled using the Enabled checkbox and set up health check for all proxy repositories by enabling Configure for all proxy repositories. With this configuration, health check will be enabled for all existing proxy repositories. Any newly created proxy repository will automatically have health check enabled as well.
Selecting Use the Nexus truststore allows seemless interaction when remote repositories are accessed via SSL. For more on adding certificates, see Section 6.10.1, “Outbound SSL - Trusting SSL Certificates of Remote Repositories”.
Available in Nexus Repository Pro only
The detailed report contains the same overview data and charts for security and license information at the top displayed in Figure 8.3, “Summary of the Detailed Repository Health Check Panel”.
Below the overview a drop-down allows you to toggle between two lists displaying further details, as shown in Figure 8.4, “The Security Data in the Detailed Repository Health Check Report”. Select View By: Vulnerabilities to inspect details of the security issues and View By: Artifacts to further review the license information. Both lists have a filter for each column at the bottom of the list that allows you to narrow down the number of rows in the table and find specific entries easily.
The security list, as visible in Figure 8.4, “The Security Data in the Detailed Repository Health Check Report”, contains columns for Threat Level, Problem Code and the GAV parameters identifying the affected component. The Problem Code column is a link to the security warning referenced and commonly links a specific entry in the Common Vulnerabilities and Exposures list. This database has descriptive text on vulnerabilities and further information with reference links.
The Threat Level is rated in values used by the vulnerability databases and ranges from 0 for a low threat to 10 for the highest threat. Critical values (noted in red) range from 8 to 10. Severe values (noted in orange) range from 4-7, and Moderate values (noted in yellow) range from 1 to 3.
The license list, as visible in Figure 8.5, “The License Data in the Detailed Repository Health Check Report”, shows a derived threat in the License Threat column. The Declared License column details the license information found in POM file. The Observed Licenses in Source columns lists all the licenses found in the actual source code of the library in the form of file headers and license files. This data is based on source code scanning performed and provided by the Sonatype Data Services.
For Maven components, the next columns for the GAV parameters allow you to identify the component. For NuGet components the columns are instead Id and Version but with the same intent.
The column Security Issues displays an indicator for potentially existing security issue for the same component.
Licenses such as GPL-2.0 or GPL-3.0 are classified as the highest License Threat and labeled as Copyleft and use red as signaling color.
A Non-Standard or Not Provided license is classified as a moderate threat and uses orange. Non-Standard as a classification is triggered by the usage of atypical licenses for open source software such as CharityWare license, BeerWare, NCSA Open Source License and many others. Not Provided is trigged as classification if no license information was found anywhere.
Licenses such as CDDL-1.0, EPL-1.0 or GPL-2.0-CPE receive a Weak Copyleft classification and yellow as notification color.
Liberal licenses that are generally friendly to inclusion in commercial products use blue and include licenses such as Apache-2.0, MIT or BSD.
A general description about the implications of the different licenses is available when hovering over the specific category in the License Analysis Summary. Detailed information about the different licenses can be obtained from the Open Source Initiative. Mixed license scenarios, like an inclusion of Apache-1.1, Apache-2.0, LGPL and LGPL-2.1 licenses, can be complicated to assess in their impact and might be legally invalid depending on the combination of licenses observed. Detailed implications to your business and software are best discussed with your lawyers.
Nexus Repository Manager Pro reports all components in the local storage of the respective repository in the detail panel. This means that at some stage a build running against your repository manager required these components and caused a download of them to local storage.
To determine which project and build caused this download to be able to fix the offending dependency by upgrading to a newer version or removing it with an alternative solution with a more suitable license, you will have to investigate all your projects.