Today, Sonatype announced "InnerSource Insight," an industry-first capability within Sonatype Lifecycle that makes it easier and safer for developers to use components developed by others within their organization.
Before we talk about the product or the functionality, we have to dig into why InnerSource is so useful and important. We'll start with a short explanation of important concepts within open source to grasp, followed by InnerSource. From there, we can explain why it's so important to manage, and what we're doing at Sonatype to make that easier.
What is a component or dependency?
To help understand InnerSource, we need to understand some foundational concepts.
The first concept is a form of reusable software code known as a "component" that is easily shared between software projects. This is similar to how a car engine is made up of thousands of parts and some of those parts may be in use across different models.
In software, most components come from open-licensed, publicly available sources that are consumed by other applications. Like a car, some parts could be thought of as a parent (like an engine) or child (like gear inside the engine). In this example, the car is parent to the engine and engine is parent to the gear.
When components become dependencies
For developers, these are just components that they use to build with, but when other software starts to rely on these components, they're often referred to as "dependencies." Here, there are two major types:
Direct dependencies - Open source components are often added directly to the codebase (or their dependency tree) by software engineers. Further, a direct dependency is referenced directly by the program itself and are the "parents." They control who their children (transitive dependencies) are, and whether or not they have any at all.
Transitive dependencies - These occur when a direct dependency requires additional open source components to run properly. These can be problematic because vulnerabilities or quality issues are often not declared or explored at this level. Because they're less accessible to developers, this makes issues difficult to remediate.
How transitive dependencies are managed
Direct dependencies are considered a "parent" project because only they make the decision to take on or change the shared components in their software. If they wish to modify something such as add a new feature or fix a problem, parent projects must modify the project code and components, and then distribute the results.
Whoever uses the updated version will also inherit all the dependencies that the shared component uses. Those dependencies are transitive, and they can exist in any software program built from components, including InnerSource.
What is InnerSource?
Remember how we noted that a component is a form of reusable software code that is easily shared between software projects? "InnerSource" is simply the sharing of components built inside one's own company.
Custom code, shared
Any worker at any company will have custom tools and policies, and developer teams are no different. They will have written some of their own tools locally, including solving everyday problems, interfaces for internal and external services, and customized code taken from public, open source repositories.
The term "InnerSource" was coined in the year 2000 to refer to the use of open source development best practices and operational culture in the development of proprietary components. InnerSource components can also include open source dependencies just like any other software program. The resulting programs, including customization, are then shared internally for use by applications within the same company.
Secure cooperation
Development teams work best when they can collaborate and code efficiently, so many organizations choose to implement an InnerSource software development strategy within their software development life cycle (SDLC).
However, because InnerSource software can use open source components, it can also bring the difficult-to-resolve transitive dependencies. As a result, understanding these dependencies is crucial to avoid outdated software or newly-found security vulnerabilities that appear in InnerSource.
What is Sonatype's InnerSource Insight?
Developers and security teams need to see what dependencies are present for their InnerSource components.
Sonatype's InnerSource Insight:
-
Shows open source dependencies brought in by InnerSource components
-
Helps quickly remediate concerns
-
Identifies safe upgrade paths that won’t break builds
Without automation, discovering violations from InnerSource components is challenging, time consuming, and painful. Developers can waste time tracking down transitive risks related to an InnerSource component and even more time determining a safe and compliant path forward.
Sonatype Lifecycle manages component risk with continuous monitoring and – if a problem is found – quickly informs you of the issue and helps fix it.
Easier remediation
Another concern is that InnerSource violations add noise to component analysis results. When violations are not clearly identified as part of a transitive InnerSource violations, finding the direct dependency and getting remediation from the provider can be a major time sink. Rather than the application focusing on the internal component (consumer), the issue should be remediated in the InnerSource component (producer).
InnerSource Insight makes dealing with internal components painless. You can clearly identify, view, and (if necessary) waive policy violations, saving your organization time and making it easy to remediate violations from InnerSource components. All inside the familiar Sonatype Lifecycle interface.
Although some Sonatype customers have already seen many of these functions in Lifecycle since our soft launch last year, we've included additional features for wider consumption, including Version Explorer and integration with CycloneDX.
You can see an introduction to the topic and our software in the My Sonatype video below:
New features in InnerSource Insight
Version Explorer for InnerSource Components
This most recent update to InnerSource Insight helps developers identify risk faster by highlighting ancestor InnerSource components of each vulnerable open source component, and pinpointing all vulnerable direct and transitive dependencies of each component.
Upgrading an InnerSource component is the most common way to remediate. However, as discussed earlier in this article, the nature of these components makes it hard to know what other component versions are available.
Like most third-party components, there are often dozens of versions, making it challenging for developers and application security teams to pick the right upgrade path. Users have to hunt down the component within their repository instance and see what else is available for upgrade.
Version Explorer for solves this issue by providing the user with an easy-to-understand view of all the available versions, pictured below:
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.
Organizations that use Sonatype Nexus Repository Manager 3 (NXRM3) as their InnerSource code repository can integrate with Sonatype Lifecycle to directly view version data of InnerSource components. This data will be available in the Version Explorer graph in the component details page, which improves issue remediation.
Connecting with CycloneDX
To make good decisions for your organization, you should first know what's in your software. Unfortunately, many organizations are still operating with no visibility. As of 2020, fewer than 50% of companies were maintaining a component list for their software.
Building and maintaining such a list, also known as a software bill of materials (SBOM), is a great first step to monitoring component software, and CycloneDX is the industry's most advanced format. Sonatype has embraced this standard because it highlights direct, transitive, and InnerSource components within your software development supply chain. Sonatype Lifecycle integrates InnerSource Insight with CycloneDX, enabling support of 120+ tools and languages to generate a detailed catalog.
Once a customer has uploaded a CycloneDX SBOM sheet from multiple projects within the same organization, Sonatype can start to detect InnerSource components. InnerSource Insight identifies the direct dependency and provides a remediation path for the associated transitive dependencies.
See an overview of these updates as well as a demonstration in the video below:
InnerSource Insight Enhancements
If you'd like to learn more about InnerSource components and how Sonatype helps you identify and remediate them within your organization, head over to our InnerSource Insight e-learning course.
