InnerSource

InnerSource components are internally developed components that are shared with other internal projects. InnerSource components are commonly built using open source. When consumed by other projects, InnerSource and its dependencies can produce many redundant policy violations in the consuming Application Composition Report. These policy violations are hard to remediate and cause a lot of wasted time because the team responsible for risk in the InnerSource Component is not the team using it. The goal of InnerSource Insight is to reduce the work needed to remediate and manage consumed InnerSource dependencies.

Version Info

Lifecycle versions between 103 and 122 showed InnerSource components with incrimental improvements. Update ot the latest version for the best results.

What is InnerSource?

To explain, let's use a common scenario that causes InnerSource violation. In this case, the InnerSource common database framework was built with open-source components that have violations.

The scenario is two projects: P and C:

Both projects have an associated IQ application.
Project P creates a common database framework that Project C uses, making project P a producer of an InnerSource component and project C a consumer of an InnerSource component.
When viewing the Application Composition Report for project C, one can now see these violations are from project P, making it easy to determine who brought in the violations.

Below is an illustration of this scenario:

Supported ways are

Java Applications
- Scan with either the Maven CLM or Gradle Plugin
Javascript Applications
- Must contain npm manifest files to identify InnerSource and other dependency types. Checkout the npm Application Analysis Documentation for more information.
CycloneDX SBOMs
- Scan with either CycloneDX Application Analysis or Third-Party Scan REST API

Requirements for InnerSource Insight

Before the consumer can use InnerSource Insight, the producers need to be evaluated by InnerSource Insight. To do this, please run the evaluation for the producers. Once the producers have been evaluated by InnerSource Insight, InnerSource Insight will be able to identify and associate with the consumers

How to use InnerSource Insight for Maven

InnerSource Insight for maven requires the producer and the consumer use the CLM Maven plugin or the Gradle plugin (v2.0.4 or higher). When both are using a supported plugin or format, the consumer's Application Composition Report will identify InnerSource components and their associated dependencies. Check out the Sonatype CLM for Maven documentation and the Gradle Plugin to learn more.

Maven and Gradle in a CI Environment

CLM for Maven and Gradle index goal is valid for InnerSource Insight in a CI environment such as Jenkins. For more information please refer to Sonatype CLM for Maven or Gradle Plugin.

How to use InnerSource Insight for NPM

InnerSource Insight for npm adopts ecosystem manifest files to identify InnerSource and other dependency types. Check out the npm Application Analysis documentation to learn more about supported npm manifests.

NEW IN RELEASE 133

How to use InnerSource Insight for CycloneDX SBOM

Experimental Feature

InnerSource Insight includes support for CycloneDX SBOM dependency graphs in Lifecycle. CycloneDX includes dependency graph support for versions 1.2 or above and as long as the generated graph follows the CycloneDX recommendations, Lifecycle will process them accordingly and produce results with dependency types and InnerSource information. Check out the CycloneDX Application Analysis documentation for more information on this.

NEW IN RELEASE 135

Version Explorer for InnerSource Components

Organizations that use Nexus Repository Manager 3 as their InnerSource code repository can integrate Lifecycle with the repository to view version data of InnerSource components. This data will be available in the Version Explorer graph in the component details page which improves remediation of issues. Refer to the InnerSource Repository Configuration documentation to learn more.

Example Application Composition Report Before and After

Before these changes, InnerSource components weren't identified, and their transitive properties were also not identified. After these changes, InnerSource is recognized and all the associated direct and transitive dependencies are indicated.

Additionally, for each InnerSource dependency, we now show a count of its transitive policy violations i.e. the number of policy violations from all transitive dependencies with this InnerSource dependency as a root ancestor.

If you hover over the InnerSource icon of a transitive dependency, then it will show you a tooltip listing its InnerSource root ancestors.

The Component Details Page also provides a link to the producer.

For transitive dependencies, the Component Details Page will add a tag next to any InnerSource root ancestors.

Additionally, for InnerSource only transitive dependencies i.e. transitive dependencies with only InnerSource root ancestors, the CIP will also show an InnerSource tag next to their transitive dependency tag in the CIP header.

Note

A dependency can be associated with both the consumer and an InnerSource component (producer). In this case, the dependency will be shown in the consumer report as Direct dependency, even though it is both Direct and Transitive.