Sonatype CLM uses the term policy to broadly refer to the set of policies and policy elements (e.g. labels and license threat groups) used to ensure components in an application meet a specific set of standard. In our Organization and Application Management chapter we colloquially compared these to rules.

The process of creating this set of rules based on specific factors is considered policy development. Combining this with the ongoing refinement and adjustment is the broader category of policy management. No matter what it is called though, the end result should always be actionable results that are representative of your organizations risk tolerance. Put a bit more simply, Sonatype CLM policy provides a means to organize risk data.

In general, policy, within the context of Sonatype CLM, is a broad term used to encapsulate:

In some ways rules as a description is a bit generic, so let’s dig a bit deeper, and look at another concept you are likely familiar with, an If/Then statement.

In fact, that’s one of the easiest ways to break down the various elements of a policy. 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. Of course, you’re still very likely exposed to quite of bit of risk.