Table of Contents
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
- Must contain npm manifest files to identify InnerSource and other dependency types. Checkout the npm Application Analysis Documentation for more information.
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.
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.
Clicking on a violation or component brings up the Component Information Panel (CIP) which provides more information on the violation and the associated components.
Component Information Panel
InnerSource Insights added some additional information to the Component Information Panel 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.
The Component Info Panel also has improvements to identify InnerSource components. The component will have an InnerSource Label in the heading as well as an InnerSource label below the component name.
Associate Violations with InnerSource
InnerSource Insights adds new labels to the Component Information Panel so you can easily identify which violations belong to an InnerSource Component and view the Application Composition Report for the InnerSource component. For transitive InnerSource violations, the Component Information Panel includes a direct link to the internal component’s Application Composition Report, making it simple to view the policy violations associated with the direct dependency.
Note the view Transitive Violations button is only available in the CIP 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.
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.
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.
Talk to Us
Have more questions or comments? Learn more at help.sonatype.com, join us in the Sonatype Community, and view our course catalog at learn.sonatype.com. And visit my.sonatype.com for all things Sonatype.