Remediation with Nexus Lifecycle

IQ Server | Reading time: 6 minutes

Is this article helpful?

NOTE: The Advanced Development Pack (ADP) capabilities have been integrated into the general Lifecycle product. These changes are accessible with IQ Server version 100 and above. For customers with IQ server versions between 100 and 134, your admin may need to re-upload your organization’s existing Lifecycle license or restart the IQ Server to see these additional capabilities.

The role of a software developer is ever-changing. As the definition of dependency management evolves, developers are tasked with not only writing code but also ensuring security and code quality. Managing all of these elements simultaneously means the developer role has become increasingly complex. This makes it critical that development teams have the tools they need to automate key processes, helping to boost their productivity while also improving security and quality.

The good news is that the market is shifting, and development teams are gaining budget authority to purchase tools that better fit their needs. This means going beyond vulnerability identification and warnings by integrating dependency management directly into their DevOps tooling.

Nexus Lifecycle’s developer features enable a more proactive approach to development teams owning security in their products, resulting in less oversight from external teams and more confidence in their projects. Development teams will gain an automated, policy-based dependency management solution, putting control back into the teams’ hands and helping them engage in proactive dependency management practices without losing the momentum of agile development.

With these Nexus Lifecycle features in place, development teams gain the following benefits:

  • Less rework and maintenance. A higher-quality selection of components means you’ll gain a better understanding of what fits organizational policy requirements.
  • Ease of upgrading. Using our recommendations and single-click migrations will lead to a decreased level of effort when upgrading to the next best OSS component.
  • Improved project quality. We’ll give you early warning of suspicious behavior in code and access to components from the best suppliers.
  • Increased bandwidth. Less time spent researching quality OSS components means you’ll have more time to innovate.

Lifecycle’s Developer Features

Lifecycle users have access to the following capabilities and features:

  • Dependency insight with the transitive solver
  • Recommendations for incompatible code with breaking changes
  • Suspicious package detection with release integrity
  • Selection of quality components with hygiene ratings

Transitive Solver

NOTE: If you experience challenges with seeing Transitive Solver recommendations, please refer to this Knowledgebase article.

Accessible in the Component Details page, Transitive Solver is a set of recommendation strategies that provides insight into a component’s known dependencies. It shows you the link between a transitive and its direct dependency and then helps you quickly focus on what to fix first and how. By providing a recommendation for the direct dependency and its transitive(s), you can be more effective at mitigating risk within your application. Leveraging the identification and linkages established for Maven, the Transitive Solver introduces additional strategies to our Recommendation Engine:

  • Next version with no policy violations with dependencies
    • Recommends the next version of the component that does not have transitive dependencies that cause violations.
  • Next version that does not fail a build with dependencies
    • Recommends the next version of a component that will not fail a build and takes into account the transitive dependencies.

example Component Details page that shows Transitive Solver

Breaking Changes

This capability helps you understand if incompatible code is introduced in the upgrade path of a component. Knowing when incompatible code — or breaking changes — is introduced helps you determine if an upgrade path is a simple version upgrade or if more complex code changes are required for that version.

example Component Details page that shows Breaking Changes

Prioritize and Automate Fixes

When there are no breaking changes between two versions of a component, there should be little effect on the code of the application itself — you should be able to simply upgrade to the new version of the component and move on. These types of fixes can be prioritized over fixes that might require additional development work. Better yet, if there are no coding changes required, the fix can be automated. Knowing the level of effort that might be required to upgrade to a version that fixes the violation helps you properly prioritize and plan for the work to be done at the appropriate time.

Better Understand Your Level of Effort

Sometimes a development effort to fix a violation is inevitable. In this case, knowing the extent of the effort required to upgrade to a version that fixes the violation helps you properly prioritize and plan for the work to be done at the appropriate time.

Release Integrity

The Release Integrity feature automatically detects risky component version releases by monitoring activity in the software supply chain, detecting suspicious behavior and flagging affected releases as such.

The Sonatype team uses machine learning automation to rapidly detect these suspicious releases at scale, letting us create an early-warning system for potentially harmful packages. This automation enhances our security research by providing a new feed of potentially malicious packages to research. This helps us protect our customers by enabling you to stop these components from infecting your development environments using Nexus Firewall before it’s too late.

Component versions with detected abnormal behavior will be rated as “Suspicious” in red on the Component Details page.

Release Integrity Rating on the Component Details page

Upgrade with Confidence

Bad actors are attacking the software supply chain by injecting malicious code into, or hijacking, legitimate projects that you might be using today. When this happens, upgrading to a newer version of a compromised project might infect your applications or systems without you realizing anything changed.

Write Policy around Integrity Rating

In addition to hijacked or infected projects, Release Integrity can detect suspicious packages that use techniques designed to trick you into adding them to your applications such as Typosquatting. Users can write policy against the Integrity Rating of a component, allowing suspicious components to be blocked at the Nexus Firewall and also brought to a developer’s attention in their Integrated Development Environment (IDE). Because Release Integrity can do this analysis quickly with machine learning automation, even the newest malicious package releases can be blocked early.

Hygiene Ratings

Health & Hygiene provides data to help ensure you are only using open source components from the best suppliers. This leads to an increase in the quality of your applications and reduces your risk of productivity loss. A supplier in this case is a project that produces the components that are consumed in your applications, such as Spring Framework or Log4j.

A Hygiene Rating is used to summarize the health of a supplier:

  • Exemplary suppliers are those that exhibit behaviors we’ve identified as important to producing quality open source software (State of the Software Supply Chain Report, 2021) within their ecosystem.
  • Laggards are the opposite end of this spectrum and should be avoided where possible.
  • Neutral suppliers lack any significant positive or negative behaviors.

Hygiene Rating on the Component Details page

Write Policy around Component Quality

Hygiene Ratings let you write policy regarding the quality of components used in applications without the need for specific inclusion/exclusion lists, or other overly prescriptive lists. By focusing on the hygiene rating, the policy can be written to protect applications from low-quality components while still giving developers the freedom to choose the best components for their particular application.

Compare Components Based on Quality

Hygiene Ratings help developers quickly do a quality comparison of components without having to do their own research. When choosing a component to fit a need such as logging, this lets them consider the highest quality components within that category and avoid the lower quality ones.

Talk to Us

Have more questions or comments? Learn more at, join us in the Sonatype Community, and view our course catalog at

And visit for all things Sonatype.