The CLM Book - Optimized Component Lifecycle Management with Sonatype CLM

When you launch Sonatype CLM for the first time, even after setting up and configuring your security parameters, there will be little to no information, a blank slate if you will.

Now, you could go off and simply start creating organizations and applications, as it’s a fairly simple process. However, it would be wiser to think about how your particular business organizes applications. For many teams this follows a "command and control" structure, or rather one where various business units are responsible for specific applications. For others, applications create more logical categories, such as internal, or perhaps, commercial units, each having sets of applications below them.

In both cases these are units which simply contain applications, and there is some correlation between each application, even if it is only surface level. This idea of containers and correlation is the exact principle behind organizations.

Organizations, when looking simply at their most basic function, serve as a container for applications. While we cover how organizations manage policy and the other policy elements in just a moment, it’s important to think about how you will set up your organizations before you begin creating them in Sonatype CLM.

Once you’ve done that though, you are ready to create an organization.

Organizations are created via the Sonatype CLM Server. Make sure you have proper access, which includes being a member of the CLM Administrator role.

There are two main ways to create an organization:

The essential difference between the two options lies in Global Create button, which simply provides access to create an organization from anywhere within the Sonatype CLM Server.

Regardless of the option you choose, to create the organization, you only need to enter a name, and then click the Save button.

OPTIONAL ROBOT: As an option, you can add an icon for your organization, but this is not required. The image should be sized to 160 x 160 pixels and use the PNG format. Images with different sizes will be scaled. Alternatively you can press Want a robot to use a robot image. Each time you click on the link, a new robot image will appear.

Earlier, we talked about a link between applications being developed, and the policy (or policies) that will be governing the components used in those applications. That link is provided by creating an application record within Sonatype CLM.

There are two main ways to create an application:

The essential difference between the two options lies in Global Create button, which simply provides access to create an application from anywhere within the Sonatype CLM Server.

Regardless of the option you choose, the information necessary to create an application is the same. Each application has three essential parts, which have been described below. Descriptions for optional items have been included as well.

So we understand the difference between organizations and applications, but how should this affect how we manage policy?

In fact the concept of policy may still be confusing. For now though, let’s just think about it as a set of rules for components you can or can’t use in your applications. Given this, each application is different, why not create policy (rules) for each individual application?

This is actually a common question when it comes to creating your policies for the first time. Our inclination tends to be to match a policy to an application. That is because we can sometimes think of applications as being very unique, and for that reason they will each have their own policies, different from other applications. This might be true. However, inheritance from an organization to an application plays a big role in making policy management much easier. Let’s look at how the concept of inheritance works.

Because an organization can have multiple applications attached, and those applications inherit policies as well as labels, and license threat groups, creating a policy at the organization level allows us to manage a single policy across hundreds of applications. With this inheritance, you can make one modification and have that change affect all, or at least large numbers of, applications.

Now, lets put this in contrast with creating a policy at the application level, which seems similar, but the lack of inheritance from one application to another changes things up.

In the case of organization level policy (rules), which appears across many different applications, the application level policy is meant for precise scenarios where the policy is only intended for a single application.

Doing this takes into account something specific we want to identify or keep out of a single application, but not others. The more of these application level policies that are created though, means the more micromanagement, and in turn, opportunity for error, will occur. So, keeping them at a minimum, and only for those unique scenarios is ideal.

This is likely better conveyed in an example. Imagine two applications with 4 policies each. Two policies for these applications are identical. If you have this setup with two separate applications, any change to the identical policies has to be done once for each application. However if we move these policies to the organization that both applications belong to, we only have to change one. Now imagine a similar scenario with a larger number of shared policies as well as applications. Without organizations to inherit from this would become unmanageable quickly.

Alright, now that you have a basic understanding of organizations and applications, let’s take a look at the basics behind developing policy.