Repository Management with Nexus
11.3. Using Repository Health Check Results For Component Lifecycle Management
The following example details how you can analyze security issues of an artifact found in your repository health check and determine a solution with the help of information available in Nexus.
After performing a repository health check as documented in the prior sections of Chapter 11, Repository Health Check, you noticed the artifact with the Group org.springframework, the Artifact spring-beans and Version 2.5.4. Upon further inspection of your software build and the components used, you can confirm that this artifact is indeed part of your shipping software.
Tip
Sonatype Insight for CI can help you with the detection of license and security issues during continuous integration builds. Sonatype App Health Check allows you to analyze already assembled application archives
A GAV search for the artifact in Nexus as documented in Section 5.4, “Searching for Artifacts” allows you to inspect the Insight tab for the artifact displayed in Figure 11.6, “Insight tab for org.springframework:spring-beans:2.5.4”.
After reading the summary and inspecting the entries for the security issues in the security databases linked in the Problem Code column, you decide that these issues affect your software and a fix is required. In order to determine your next steps you search for all versions of the spring-beans artifact. As a result you receive the list of all versions available partially displayed in Figure 11.7, “Viewing Multiple Versions of org.springframework:spring-beans:x”. The security column in the search results list displays the count of two security issues for the version 2.5.4 of the library.
Looking at the Security Issues column in the results, allows you to determine that with the uprade of the library to version 2.5.6.SEC02 the count of security issues dropped to zero. The same applies to version 2.5.6.SEC03, which appears to be the latest version of the 2.x version of the artifact. In addition the table shows that early versions of the 3.x releases were affected by security issues as well.
With these results, you decide that an immediate update to version 2.5.6.SEC03 will be required as your next step. In the longer term an update to a newer version of the 3.x releases will follow.
The necessary steps to upgrade depend on your usage of the spring-beans library. A direct usage of the library will allow you to upgrade it directly. In most cases this will require an upgrade of other SpringFramework libraries. If you are indirectly using spring-beans as a transitive dependency, you will need to figure out how to upgrade either the dependency causing the inclusion or override the version used.
The necessary steps will depend on the build system used, but in all cases you now have the information at your hands why you should upgrade and what version to upgrade to, which allows you to carry out your component lifecycle management effectively.
The following example details how you can analyze a license issue of an artifact found in your repository health check and determine a solution with the help of information available in Nexus.
Your repository health check detail report indicated that Hibernate 3.2.7.GA might have issues due to its Threat Level declared as Non-Standard. Looking at your software artifacts you found that you are indeed using this version of Hibernate. Searching for the artifact in Nexus provides you with the search results list and the Insight tab for the specific version displayed in Figure 11.8, “Viewing License Analysis Results for Hibernate”.
The Insight tab displays the declared license of Hibernate is the LGPL-3.0 license. Contrary to that the licenses observed in the source code include Apache-1.1, Apache-2.0, LGPL-2.1, LGPL and Non-Standard.
Looking at newer versions of Hibernate you find that the observed license in the source code changed to Not-Provided. Given this change you can conclude that the license headers in the individual source code files were removed or otherwise altered and the declared license was modified to LGPL-2.1.
With this information in hand you determine that you will need to contact your lawyers to figure out if you are okay to upgrade to a newer version of Hibernate to remedy the uncertainty of the license. In addition you will need to decide if the LGPL-2.0 is compatible with the distribution mechanism of your software and approved by your lawyers.
In the above steps Nexus provided you with a lot of information allowing you to effectively carry out our component lifecycle management with a minimum amount of effort.