Skip to main content

Component Identification

After the identification effort is complete, the Lifecycle assigns components a match state. These match states trigger policy violations and clue into potentially risky components.

Match States

The match state is used to identify the pedigree of the components within your application. Lifecycle gives components one of three possible match states.

Match State



Indicates that Sonatype has exactly matched your component with the component's identity source. This typically means that the component has a SHA1 hash match of the component as it exists in a public repository. This is the same for components identified by other sources.


Indicates that Sonatype can't match your component to a component recognized by Sonatype Intelligence. These can be components that you have developed, from third-party sources, or possibly added from another source. When you are not able to determine the source of these artifacts, they present a significant risk to your application.


The Similar match state is provided to for Java components when the component has most of the same files as a public component however they have been changed in some ways. These components present unknown risk as to why they were changed and technical debt when dependent on a modified version of the public component; making updating dependencies difficult. They potentially present a weak copyleft license risk by using modified components.

When a component has a match state of Unknown, it usually means that Lifecycle wasn't able to match the component to other components in a public repository like Maven or npm. This could happen because:

  • The component is proprietary to your organization and has not and will not appear in a public repository.

  • The component originated from a public repository but has been changed by a developer at your organization in order to patch bugs, improve a function, etc.

  • The component is not proprietary but is also not from a public repository (e.g. a developer grabbed a package that lives exclusively on GitHub, GitLab, etc).

  • The component originated from a public repository but has been altered with malicious code.

Similar Matching

Similar matching is an advanced feature of Lifecycle for Java applications. When a component's hash is similar, but not identical, to a known Java component, Lifecycle gives it the Similar match state.

Similar matching gives you a more accurate picture of the components in your application. In reports, Lifecycle displays information about the component that best matches what it finds in your application. This can help alert you to risks that are probably in your application, even if positive identification isn't possible.

It's important to understand that components in your application can be partially matched to more than one component that Lifecycle recognizes. Lifecycle selects the best match and shows component information and policy violations based on the best match, but you may want to see the other components that are partial matches. See Finding a Component's Match State below.

Finding a Component's Match State

To identify a component's match state, open the Component Details Page for that component. Match State and Identification Source information can be found at the top of the page.


If your component has been given a match state of Similar, you'll see the option to View Similar Matches, like in the example below. Click to see a list of other components that are partial matches to the component in your application.


Identifying an Unknown Component

Components with a match state of Unknown or Similar represent a risk to your application and should be investigated.If your investigation reveals that the component is okay, then use one of the methods below to make sure that your Lifecycle scans are as accurate as possible.

Innersource Insights

The topic of claiming unknown components has significant overlap with Innersource Insights, an advanced feature of Lifecycle that allows you to mark certain components as "Innersource." This means that they're internally developed but not under your direct control.

Learn more about Innersource Insights in our documentation.