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.
How Proprietary Matchers Work in Different Scan Types
Proprietary matchers behave differently depending on whether the component comes from a manifest file or a binary (e.g., a .tgz
, .jar
, or .dll
file):
Scan Type | Proprietary Matcher Result |
---|---|
Binary Scan | Component appears in the report and is marked as proprietary |
Manifest Scan | Component is excluded entirely from the report |
This means that if a component (e.g., from a package-lock.json
) matches a proprietary regex, it will not show up in the report; it is silently skipped.
Note
Proprietary .dll
and .js
files are not included in application reports. This applies regardless of whether the match is from a manifest scan or a binary scan. IQ Server excludes these components from report output even if they are identified as proprietary.
Method One: Through the Orgs and Policies screen
In the browser UI, on the left, click Orgs and Policies on the left toolbar.
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.
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.
![]() |
To add a new proprietary matcher, use the drop-down menu at the bottom of the list.
![]() |
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
In the browser UI, click Reports on the left toolbar.
Click View Report for any application.
Click any unknown component. If you're using our default policy set, look for a component flagged for the Component-Unknown violation.
At the top of the Component Details Page, you'll see a warning. Click Add Proprietary Component Matchers.
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.
Filtering Results by Proprietary Matchers
Inside an Application Composition Report, you can filter for proprietary components by clicking the Filter 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
or .js
files, IQ Server does not include those components in the application report. This is intended behavior, even for components scanned from binaries.
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".
Important Note about Manifest Files
When a component in a manifest file matches a proprietary component matcher (either a package matcher or a regular expression), it is automatically excluded from identification. This means it will not appear in the application report, and it will not trigger any policy violations (e.g., License-None or Component-Unknown).
This behavior is different from binary scans, where matched proprietary components are included in reports and marked as proprietary.