The CLM Book - Optimized Component Lifecycle Management with Sonatype CLM
- 7.1. Organization and Application Management
- 7.2. Policy Development
- 7.3. Policy Creation
-
- 7.3.1. Step 1: Understand the Policy Intent
- 7.3.2. Step 2: Decide on a Descriptive Policy Name
- 7.3.3. Step 3: Choose an Appropriate Threat Level
- 7.3.4. Step 4: Choose the Application Matching Parameters
- 7.3.5. Step 5: Create Constraints with Conditions
- 7.3.6. Step 6: Set Policy Actions And Notifications
- 7.4. Policy Elements
- 7.5. Labels
- 7.6. License Threat Groups
-
- 7.6.1. Creating, Editing, and Deleting a License Threat Group
- 7.6.2. Creating a Condition Based on a License Threat Group
- 7.6.3. Creating a Condition Based on an Unassigned License Threat Group
- 7.6.4. Tags
- 7.6.5. Creating, Editing, and Deleting Tags
- 7.6.6. Applying a Tag
- 7.6.7. Matching Policies to Specific Applications
- 7.6.8. Viewing Tag-based Policies
- 7.7. Evaluating via the CLM Server
- 7.8. Reviewing Evaluation Results
- 7.9. Importing Policies
- 7.10. Policy Monitoring
When we talk about policy within the paradigm of Sonatype CLM, we refer to it as a way to identify and reduce risk through a concise set of rules for component usage. These rules can be used to assist at every step of the component and development lifecycle, and can be customized for specific applications and organizations. In general, policy, within the context of Sonatype CLM, is a broad term used to encapsulate:
- Conditions
- Actions
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.
Now, let’s take a slightly closer look, and define the basic policy anatomy. There are actually three key parts to a policy:
- Conditions
-
conditions are the
ifpart of theif-thenstatements. - Constraints
- a constraint is really just a way to organize multiple conditions (if-then statements). Our example only had one so far. Let’s say we decided we wanted to add that if a security issue is found and it has a CVSS of 2 or lower, only a warning should occur, but the release should not be prohibited.
- Actions
-
actions are simply the
thenpart of the if-then statement. Basically, what you want to have happen.
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?"
Policy is managed within a set of containers, organizations and applications, within Sonatype CLM. We’ll discuss those in the next section.