Managing InnerSource Components with InnerSource Insights

IQ Server | Reading time: 6 minutes

Is this article helpful?

Table of Contents


Welcome! The content of this Guide is being moved to [ See this page to learn more about InnerSource Insights.

InnerSource Insights is the new way to identify and manage InnerSource Components with Nexus Lifecycle. Identifying violations from InnerSource components is challenging and time consuming. These violations add noise to the results as they should be remediated in the InnerSource component (producer), rather than the application using the internal component (consumer). When violations are not clearly identified as transitive InnerSource violations, finding the direct dependency and getting remediation from the provider can be a time sink.

InnerSource Insights makes dealing with InnerSource components easy. You can clearly identify, view and waive InnerSource violations. This saves your organization time and makes it easy to remediate violations fromInnerSource Components. In this guide we’ll provide a brief overview of InnerSource and explain how to manage these components with InnerSource Insights.


  • IQ Server 122 or later
  • The InnerSource component must be scanned with Nexus Lifecycle prior to scanning the consuming application
  • Java Applications
  • Javascript Applications

What is InnerSource?

InnerSource is defined as “the practice of applying open source software development methodologies to internal or proprietary software components.” This means that organizations using InnerSource practices allow anyone in their organization to use and contribute to their internal software components.

Some common features of InnerSource include:

  • Making development artifacts, code, and documentation available to the entire organization
  • Letting developers self-select tasks
  • Early feedback
  • Frequent releases

The practice of InnerSource came from the success of Open Source Software (OSS). OSS became ubiquitous by creating high-quality, free components and many organizations want to emulate this model to get similar results. By implementing InnerSource practices, groups expect to save time and prevent rework by sharing existing software, creating higher quality software, and empowering their team members to make improvements across the organization. In InnerSource there are two roles, the Internal package used in another application, or the producer, and the application using the InnerSource Component, called the consumer.

InnerSource and Software Composition Analysis

Before InnerSource Insights, Nexus Lifecycle couldn’t identify the InnerSource component. These internal components would show up as unknown components and have no association with their transitive dependencies. Developers needed to manually identify and associate InnerSource with its dependencies, creating a lot of work.

Unlike violations from external dependencies, violations brought in by an InnerSource component’s dependencies need to be addressed in the producer, not the consumer. This creates confusion in the scan results as not all violations need to be addressed in the consumer. Determining which violations belong to InnerSource components can be challenging and time consuming.

With InnerSource Insights, we’ve made it easy to identify InnerSource components, associate transitive violations with an InnerSource Component, and remediate policy violations with Group Waivers.

Identify InnerSource Components

All InnerSource Insights features are available in both the Lifecycle user interface as well as the REST API. Checkout the technical documentation for the REST API for more information.

In the Lifecycle UI, information about InnerSource components are included in the Application Composition Report.

Application Composition Report

InnerSource Insights makes it easy to identify which components and policy violations are from InnerSource Components on the main Application Composition Report screen. In the Component column, there is now a teal IS Icon. This icon appears alongside the T (Transitive) and D (Direct) Icons to let you identify direct and transitive InnerSource violations at a glance.

InnerSource Logo in the Application Composition Report

We’ve also updated our component filter to provide more information for InnerSource components. Now when searching for an InnerSource component, you’ll see the number of transitive violations alongside the main component.

Filtering shows transitive violations count

Clicking on a violation or component brings up the Component Details Page, which provides more information on the violation and the associated components.

Component Details Page

InnerSource Insights added some additional information to the Component Details Page to make it clear when a component is an InnerSource component.

There is now an additional Label for Transitive InnerSource Components in the Component Info Tab next to the identifier for the component that brought in the transitive dependency. Dependencies exclusive to InnerSource components now have an InnerSource Icon in their heading, along with the Transitive Dependency label.

Component Details Page showing transitive dependency

Associate Violations with InnerSource

InnerSource Insights adds new labels to the Component Details Page so you can easily identify which violations belong to an InnerSource Component and view the Application Composition Report for the InnerSource component.

Component Details Page showing link to the producer's Application Composition Report

For transitive InnerSource violations, the Component Details Page includes a direct link to the InnerSource’s Component Details Page, making it simple to view the policy violations associated with the direct dependency.

Component Details Page for InnerSource Component

Note the view Transitive Violations button is only available in the Component Details Page for the InnerSource component - Not any of the transitive components.

We’ve added a View Transitive Violations button and a View Existing Waivers button on the policy tab. These will take you to a new screen that lists only the transitive violations brought in by your InnerSource component.

Report showing only transitive violations

Transitive Violations can also be queried using the REST API. To find out more about the Transitive Violations API endpoints check out our documentation.

Remediation with Group Waivers

The Transitive Violations screen provides a button to request or apply a Group Waiver to all violations brought in through your InnerSource component. The Request Waiver button brings up a panel with the information your application owner needs to process the waiver request. The waiver request process should be logged or tracked in your internal remediation workflow outside of Nexus Lifecycle. The Waive Violations button allows you to waive all transitive violations from an InnerSource component and reduce noise on the application’s report in a single action.

panel for requesting waivers for all transitive violations

Next Steps

The group waiver is a great tool for clearing policy violations from InnerSource components, but removing violations from the consumer does not remove risk from that component. Be sure to update InnerSource components regularly. Whenever possible, work with the teams or individuals responsible for the InnerSource component to ensure your applications meet your organization’s standards.

Additional Resources

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.