- Match States
- Similar Matching
- Finding a Component's Match State
- Using Match States in Policies
- Identifying an Unknown Component
- Innersource Insights
Lifecycle uses a variety of methods to identify the components in your applications. Get an overview of Lifecycle's primary scanning mechanisms here.
After this identification effort is complete, Lifecycle assigns components a match state. These match states can trigger policy violations and clue you into potentially risky components.
Sonatype Lifecycle can give components one of three possible match states.
Indicates that Lifecycle has exactly matched your component with a component recognized by Sonatype Intelligence. Usually, this means that the component in your application exactly matches the component as it exists in a public repository.
Indicates that Lifecycle can't match your component to a component recognized by Sonatype Intelligence.
The Similar match state is only given to Java components. Indicates that your component resembles, but doesn't positively match, a component recognized by Sonatype Intelligence.
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 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.
Using Match States in Policies
Match state can be used as a policy condition. Learn more about policy conditions and making a policy that uses match state at our documentation here.
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.
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.