Skip to main content

InnerSource Best Practices

Introduction

InnerSource Insight is a feature in Sonatype Lifecycle that identifies proprietary components in your scan results. This tells you when risk in your application is coming from other internal components, saving you time tracking down vulnerabilities that another team is responsible for remediating. Without InnerSource Insight, these proprietary components show up as Unknown Components. Researching the associated open-source dependencies can be challenging. Associating transitive risk with proprietary components can take a lot of time with little reduction in your applications' risk.

Configure your scans so that you see InnerSource identified in your results

Configure your application scans to identify InnerSource Components

  • To get InnerSource Results:

    • JavaScript - include the package-lock and the package.json files as scan targets along with your application.

    • Java - scan your application with the Maven CLM or Gradle Plugin.

    • All other ecosystems - include a cycloneDX Software Bill of Materials with your application.

  • Without InnerSource Insight, internally developed components are listed as Unknown Components in the Lifecycle scan results. Unknown components can be difficult to identify and remediate as they require your development teams to find the package in the application and determine where it originated. When these components are developed internally by another team there aren't many options for remediating transitive risk from that application. Identifying these components in your scan results allows you to identify the components immediately, waive the component, and contact the development team responsible for that component about any unacceptable risks. All of this saves time and lets you be more focused on your remediation efforts.

Include a CycloneDX Software Bill of Materials (SBOM) with identifying information for all projects

  • Including a CycloneDX SBOM in your application will identify InnerSource components regardless of the application ecosystem.

  • Including an SBOM in your application file will reduce the need to claim components and use the proprietary component configuration. Relying on a CycloneDX SBOM to provide identifying information for the component allows Sonatype Lifecycle to identify it as an internal component. Without InnerSource Insight results these components will appear as components unknown.

  • Placing a Software Bill of Materials in your application files allows the application to be identified as an InnerSource component if it is consumed by another application in the future. Even if the application is not currently intended to be consumed by other internal projects, that may change in the future. Including an SBOM in all projects ensures the application will be identified as InnerSource.

  • Including a Software Bill of Materials ensures your application has an SBOM for easy audit and compliance purposes. See our SBOM Best Practices for more information.

Follow normal waiver practices with Innersource

Follow your normal waiver practices with InnerSource Components

  • You are responsible for the risk in your application regardless of where that risk originated. The risk brought in by internally developed components is no exception. The risk from these components should be reviewed regularly and monitored like the risk from any other components.

Use bulk waivers to remediate dependencies introduced through Innersource components

  • It's often not possible to remediate the risk brought in by InnerSource components. Use bulk, time-based waivers to give other internal teams the time to remediate risk and then assess your InnerSource on a regular basis.