Skip to main content

Proprietary Component Configuration

Proprietary components are components that are unique to your organization. Lifecycle will not normally recognize these components. If you're using the default policy set, Lifecycle will flag them as violating the Component-Unknown policy.

You can configure IQ Server to recognize proprietary components. This can help reduce noise in your reports, keep you from investigating safe components, and help you identify when changes to proprietary components have been made.

Method One: Through the Orgs and Policies screen

  1. In the browser UI, on the left, click Orgs and Policies on the left toolbar.

  2. Select the level of the hierarchy you want to configure. Configuring the Root Org or Org at this step will also force IQ Server to recognize proprietary components at every hierarchy level below it.

  3. Scroll down to the Proprietary Component Configuration section and click the chevron.

Here, you'll see a list of existing proprietary component matchers. Click the trash bin icon to remove a matcher.

103907350.png

To add a new proprietary matcher, use the drop-down menu at the bottom of the list.

103907347.png

Package Matchers

For Package, specify a package name, like com.sonatype. All components that contain a package with the same file structure will be marked as proprietary. Be as specific as possible.

For the example com.sonatype, IQ Server will match all of the following content locations:

  • com/sonatype

  • com/sonatype/anything

  • com/sonatype/anything/more

  • shaded/and/relocated/com/sonatype

  • shaded/and/relocated/com/sonatype/anything

But these locations will not be matched.

  • org/sonatype

  • com/sonatypestuff

  • com/sonatypestuff/anything

Regular Expression Matchers

For Regular Expressions, specify a regular expression that will be compared against the paths of all files scanned. If a file is found in the path, it is flagged as proprietary. For example, test\.zip will recognize anything in the top-level directory named test.zip as proprietary. On the other hand, .*/test\.zip will find test.zip nested anywhere in the scanned binaries.

Occurences inside an identified archive will make the binary proprietary as well. For example, if a proprietary .zip is found inside a .jar, the .jar is also considered proprietary.

For more information on regular expressions, see the Java Documentation.

Method Two: Clicking an Unknown Component in a Report

  1. In the browser UI, click Reports on the left toolbar.

  2. Click View Report for any application.

  3. Click any unknown component. If you're using our default policy set, look for a component flagged for the Component-Unknown violation.

    103907351.png

  4. At the top of the Component Details Page, you'll see a warning. Click Add Proprietary Component Matchers.

    103907354.png

  5. A new tile will appear. Check the box and click "Add". You can also add a regular expression. See the section above for more information about regular expression matchers.

    103907355.png

Filtering Results by Proprietary Matchers

Inside an Application Composition Report, you can filter for proprietary components by clicking the 103907356.pngFilter button on the right. The first option in the list will be Proprietary: open the chevron and check a box to only see proprietary or non-proprietary components in the report.

Note: When you set proprietary component matchers for .dll files, IQ Server will not retrieve the details in the application report.

Manifest File Components

Sonatype Lifecycle includes various manifest file scanning and coordinate-based matching support.

A component in a manifest file has a path "file/component_name" e.g. for a Nuget component named "some_component" in a file named "acme.project.csproj" its path would be "acme.project.csproj/some_component".

For package matchers, periods and forward slashes are taken as package separators, and so in this example "acme", "project", and "csproj" are taken as separate packages which could be matched.

For regular expressions, these can also be used to match the derived path.

The "component_name" is determined by the component's coordinates and these depend on the format. For almost all formats, this is either the "packageId" or "name" coordinate. The exceptions are Maven, which uses "groupId" and "artifactId", and Composer, which uses "namespace" and "name".

If a component in a manifest file is matched by either a package matcher or a regular expression, then the component will be excluded from identification automatically. Any proprietary component that does not match any of the configured patterns above will be included for matching.