Component Identification


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.

Match States

Lifecycle can give components one of three possible match states. See the table below.

Match StateDescription

Indicates that Lifecycle has exactly matched your component with a component recognized by Nexus 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 Nexus 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 Nexus 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

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 a 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.

Claiming a Component

Sometimes a component with a match state of Similar or Unknown can be positively identified by you or a team member. You can claim components like this. In future scans, Lifecycle will give them the Exact match state.

To claim a component from an Application Composition Report:

  1. Find a component in the report with a match state of Similar or Unknown. If you're using our default policy set, Unknown components will be flagged for a policy violation with a severity level of 2.
  2. Click the component. You'll see an information box at the top of the page, as in the example below.
  3. Click Claim Component. This creates form fields, like in the example below. Group ID, Artifact ID, Version, and Extension are mandatory fields. Being as thorough as possible here will help reduce confusion in future scans.
  4. Click Claim at the bottom right to save your work.

The next time you scan, or re-evaluate, the component will have a match state of Exact, and the Identification Source will be Manual.

Editing or Revoking a Claim

To edit or revoke a claim, click the component in question and then click the Claim tab at the top of the Component Details Page. Use the red Revoke button at the bottom right to revoke the claim entirely, or edit the fields and click Update at the bottom right to save your changes.

Adding Proprietary Component Matchers

Usually, a component you mark as proprietary is unique to your organization and not derivative of a component that was pulled from a public repository. See more about configuring proprietary components at our documentation here.

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. Read more about this feature and how to use it at our documentation here.