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 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.