Sonatype CLM Server - Application Composition Report

5.2. Managing Proprietary Components

Simply put, proprietary components are those components that are unique to your organization. In many cases these are actually developed by your organization and distributed among the applications you develop.

As with matched components, proprietary is one of the options included in the Filter on the Policy tab of the application composition report. Unfortunately, there is often a little bit of confusion around identifying a proprietary component, so lets start first with what a proprietary component is.

figs/web/app-comp-report-proprietary.png

Figure 5.3. Proprietary Component

First and foremost, it’s important to point out that a component identified as proprietary is not "matched" as proprietary.

Identifying a component as proprietary is separate from our matching process. In this, a component identified as proprietary will also be assigned to one of three match states: similar, exact, or unknown. In most cases a proprietary component is unknown. As a suggestion for figuring out which of your components are proprietary, a good place to start is by reviewing unknown components.


	Policy can be set in such a way as to exclude components marked as proprietary from triggering violations. Care should be taken in using that condition.

To set up proprietary identification, follow these steps:

First, make sure you are logged into the Sonatype CLM Server with admin-level permissions (a member of the Global Role, Admin).
Click the System Preferences icon , and then the Proprietary Components option.

Sonatype CLM provides two methods for identifying proprietary components.

Method 1: Add packages that are considered proprietary. For example, if we entered com.sonatype, all components that contain a package com/sonatype would be marked as a proprietary component, and therefore not evaluated. Care should be taken to be as specific as possible here, as the provided package is compared greedily against your scanned binaries. For instance, if you specify com.sonatype it 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
  
  On the other hand, the following locations would not be matched for our example:
- org/sonatype
- com/sonatypestuff
- com/sonatypestuff/anything

Method 2: Enter a regular expression, which will be compared against the paths of all files scanned. This is provided as a means for recognizing components as proprietary based on the existence of a specific file within them.

If you choose this option, make sure to click the Regular JAVA Expression (RegEx) check box. For more information on regular expressions, check out Oracle’s Java documentation.

An example of a regular expression might be test\.zip. In this example anything in the top level directory named test.zip would be marked as a proprietary component. If you wanted to apply this to match a file named test.zip nested anywhere within the scanned binaries, use .*/test\.zip.


	Occurrences inside the 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.

After entering your proprietary component identification, click the Add button. This will queue your new proprietary component identifier for saving. Additionally, click any remove icon (resembles a minus symbol) in the list to remove an entry. No changes will be persisted to the server until you click the Save button.

figs/web/clm-server-proprietary-packages-configuration.png

Figure 5.4. Proprietary Packages Configuration via the Sonatype CLM Server

Once your proprietary components are configured Sonatype CLM will look at the component and the directory structure of the application being evaluated. If it matches your proprietary component configuration, it will be identified as proprietary and displayed accordingly in the reports.

Remember, proprietary is not a type of match. Most proprietary components will still be identified as unknown. That’s not a hard fast rule, but it is the most common case.


	The proprietary component changes will not be evaluated against existing reports, but will be picked up on the next evaluation.