The CLM Book - Optimized Component Lifecycle Management with Sonatype CLM

An important aspect of license threat groups is that each one also has a threat level, just like policy (from zero signifying no threat all the way up to 10). Unless you have specific legal recommendation / council, the default license threat groups will suffice, especially in the beginning.

If you desire, you can edit these default groups, or create entirely new ones. When creating license threat groups, keep in mind that they will be inherited from the organization to all associated applications.

There are two key ways to create a license threat group:

There is really no difference here, as both require that you have the organization or application open at the time of creation. The one advantage with using the Global Create button is that you can create no matter which tab of the currently selected organization or application you are in, whereas you will need to be on the License tab otherwise.

The following information needs to be completed before a license threat group can be saved.

On the left are licenses that are included in the license threat group. Click on a license to remove it.

+ On the right are the licenses that can be added the group. Click on a license to add it.

When everything is done your screen should look like Figure 7.17, “Creating a Label Condition” and you can click the Save button to finish.

A few things to remember:

In the example below a new condition for the license threat group, Banned Licenses, will be added to an new policy.

In our instructions, we’ve made an assumption that you understand how to create a policy.

In most cases, a license is associated with one or more License Threat Groups. However, it is possible for a license to have no association with any License Threat Group. You can create a Policy to detect when a component has a license that is not assigned to any License Threat Group.

In the example below a new condition for detecting components with licenses not assigned to any License Threat Group will be added to a new policy.

In our instructions, we’ve made an assumption that you understand how to create a policy.

A violation of the policy above can be remediated simply by assigning the license involved to a License Threat Group.

To remediate a specific component, use the Component Information Panel (CIP) License tab to set the license Status to Selected or Overridden, and then select a license that is associated with at least one License Threat Group. Managing component licenses is discussed further in the editing License Status and Information section of the Application Composition Report chapter.

In any given business, you could have hundreds, maybe even thousands of applications. Even if you are just getting started, it’s likely you have a handful of applications. However, as unique as applications can be, they tend to share some similarities.

For example, you might have applications that process or store sensitive information, maybe even personally identifiable information for your users. Since attacks are often aimed at these types of applications, you will definitely want to make sure your policies that identify high and critical threat security vulnerabilities are included during the evaluation of these types of applications.

Unfortunately, especially as the number of applications in your business increases, identifying an application by name may not be helpful. To address this, tags provide a way to quickly identify characteristics of an application.

Using specific text and color, tags can help group particular applications with similar attributes. While the tag can ultimately be anything you want, and attached to any application, you will want to take a much more thought-out approach, similar to what is recommended for labels.

As we will see later, in order to maximize the benefits tags can offer, you will want to take advantage of tag matching between policies and applications. For now though, let’s see how to create, apply, and delete tags.

Tags are created, edited, and deleted at the organization level and then applied individually for each application. There are two key ways to create a tag, again, only done at the organization level.

There is really no difference here, as both require that you have the organization open at the time of creation. The one advantage with using the Global Create button is that you can create a tag no matter which tab of the currently selected organization you are in, whereas you will need to be on the Tags tab otherwise.

There are three elements of tag:

The color selection is left to however your organization chooses to implement. The default is white.

If you made a mistake and want to edit the tag, simply click on the tag body (anything but the x), and you can edit the tag information. However, if you want to permanently delete the tag, click on the x.

Depending on how your business uses tags, and establishes control within CLM, the people applying tags may be different from those creating them. It is important though to understand that while tags are provided to identify characteristics of an application, a more important usage is to provide a way for policy managers to create specific policies that consider those application characteristics. For this reason, when applying a tag, your application may be evaluated by a specific set of policies. This is a good thing, but it also makes the application of tags an act that requires careful consideration. To apply a tag to an application, follow the instructions below.

By now, you have likely created tags, and perhaps even applied some to your applications. Those are great features, but the real power of tags comes when we match a policy to a specific set of applications.

Up to this point (before tags), an organization-level policy would apply to all applications. To address this, you could create a new organization, or develop specific policies for each application, but in both cases, that results in a lot of micromanagement. In contrast, tags provide an opportunity to create a policy and then pick unique groups of applications (based on their applied tags) the policy should be evaluated against.

Given this, it is important to think about the applications your business develops, as well as the types of policies you will use to evaluate your applications. Elements like the type of data, the exposure (public or private), as well as whether or not the application interfaces with the Internet, are a great place to start.

When you create your tags, make sure that it’s clear to users that will be using the tags. In other words, it shouldn’t be ambiguous as to the type of applications the tags represent. For example instead of creating the tag, External, a more descriptive tag would be Distributed. Some additional tag suggestions might be:

These are just suggestions of course, but you should get the key point. When adding a tag to an application, you can expect policies that have identified the same tag to be evaluated against your application.

Now, that’s quite a bit of discussion on the theory and proper way to utilize tags, let’s take a look at how to make the match happen.

To select the tag a policy will be evaluated against:

Policies that have been set to match applications with specific tags are visible in the same area as all other policies. However, there is a slight difference between what is displayed at the organization level and the application level.