The CLM Book - Optimized Component Lifecycle Management with Sonatype CLM

One of the easiest way to break down the various elements of a policy, at least the most basic parts, is to think of a policy as an If/Then statement. That is, a policy simply says that if something happens, then perform a certain action. If a component meets a set of criteria, then take a certain action, or in some cases no action at all.

If it’s still a bit fuzzy, an example will probably help. Let’s say we have a known rule in our development organization that says if a component used in an application has a security vulnerability, the application can not be released. To do this, we tell our development team to review components before release and if a component has a security issue, we don’t promote the release. Congratulations, you have formed, at least in the aether, your first policy.

Now, let’s take a slightly closer look, and define the basic policy anatomy. There are actually three key parts to a policy:

The above does a good job of telling us what makes up a policy in Sonatype CLM, but you are likely thinking, not all policies should be the same, I need a way to demonstrate which policies are the most important. We thought that too, and that is why in Sonatype CLM, all policies are assigned a threat level ranging from zero to ten (0-10). This score is completely subjective and will be unique in your organization.

OK, so now that we’ve opened up our concept of policy a bit, exposing the inner workings so to speak, the next question you should have is, "Where do we create policies?"

Well, as you likely recall, we can manage policy for both organizations and applications. We’ve learned a bit about these already, but let’s go ahead and have a quick review.

As a quick overview, the differences between an organization and application are as follows.

Ultimately this allows you to avoid micromanagement. For example, let’s say there is a policy that says no component can have a security violation score greater than 3. This rule should apply to a number of applications that are all associated to a particular organization. Thanks to inheritance I can create a policy for the organization and all applications will inherit this policy. This also means I won’t need to make changes to the policy for each application, rather I only make the change once, at the organization level, and it will affect any application attached to that organization. This policy will also apply to any additional applications I create under this organization in the future.

The important thing here, is to start thinking about policy more holistically. This is even before you begin to create policy in Sonatype CLM, you should think about where your policies will be created, and what applications will share similar policies. If nothing else, start writing out policies you would like to experiment with. Communicate those to your teams and start incorporating a proper feedback loop.

This section was all about policy. It’s primarily theory, but theory that is quite important for your practical implementation. Sonatype CLM will build on everything discussed here. As a recap, here’s what you should walk away with: