Optimized Component Lifecycle Management with Sonatype CLM

We just learned all about creating policies. Constraints, conditions and even actions, all make a lot of sense, but what in the world could labels have to do with policy?

Well, labels are actually one of the more powerful features of Sonatype CLM. They should have a familiar look, since you’ve likely used other systems that employ a sort of tagging or labeling.

Labels are metadata. More specifically a label is metadata that is assigned to a component within the context of a particular application or organization. Labels can assist with identifying components you want to review, approve, or even avoid altogether. We call this label assignment.

When labels are assigned, this is an action that takes place in the application composition report. Before it can be assigned though, a label needs to exist for a particular organization or application.

As we learned in our section regarding Organizations vs. Applications, inheritance plays a big role in policy. The same thing is true for labels, in that if a label is created in an organization, any application attached to that organization will also have the label available for use when assigned. In fact, the system will prompt you to choose the scope (organization or application) a label should exist in when it is assigned.

Now, assigning a label is an important action, but how do we build policy around this? That’s actually simple, we just add a condition, based on a specific label that you have created, being present. The one caveat, is that the label needs to exist within the application or the organization in which you are creating the condition.

Figure 3.8. Creating a Label

Remember that applications inherit labels from the organization they are attached to and just like for policy development in general, it will help to plan ahead what sort of labels you are going to create and use.

For this example, let’s say we want to identify components that have been approved for usage by the software architects in the development team with a label "Architecture Approved." This approval is part of the development process. We always ensure a component has gone through an approval process for architectural suitability, and when approved, they receive an "Architecture Approved" label.

After creating a label in the desired organization or application as described in Section 3.6.2, “Creating a Label”, proceed to create the condition:

Figure 3.9. Creating a Condition Evaluating a Label

The created condition will be violated by any component that does not have approval as determined by the association of the label Architecture-Approved to it.

License threat groups, are simply groups of licenses, broken into categories of severity for the various types of licenses. They can help you to achieve your goals related to enforcing the usage of components with licensing that matches the scope of your application.

Their primary purpose is to serve as the data points for the License section of the application composition report. Moreover, they are a way to group risk, associated with licensing. By default, there are four license threat groups included 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. However, they can be edited. In fact, entirely new ones can be created altogether. Let’s use that premise, and create a new license threat group, Banned Licenses. When creating the license threat group, keep in mind that they will be inherited from the organization to all associated applications.

Figure 3.10. Creating a License Threat Group

After we have created a license threat group as described in condition Section 3.6.5, “Creating a License Threat Group”, lets create a condition based on it.

Figure 3.11. Creating a Condition Evaluating a License Threat Group

The created policy will be violated by any component that is licensed under the AGPL or AGPL-3.0 license.

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 and deleted at the organization level and then applied individually for each application. Unlike other policy elements, tags cannot be created at the application level.

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.

It can be easy to forget about policy elements, and in most cases these should be reserved for more advanced users. For example, deciding what labels to use, and binding them to a specific process is very important in helping to ensure they aren’t overused. Equally important is creating tags that will provide an automatic evaluation of applications against policies with matching tags. In the case of license threat groups, you likely want to consult your legal team to make sure you remain compliant to parameters they have established. In fact, if you haven’t already they should be included in your policy development discussions.

As far as this section goes, here’s what you should have taken away.