Optimized Component Lifecycle Management with Sonatype CLM
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 the past, 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.
Before we expand on risk, let’s dig a little deeper, and really take a look at what we mean when we talk about policy, expanding everything that goes into its development.
If you have taken a look at any of Sonatype CLM documentation or poked around the imported policies in the Sonatype CLM server user interface, you may have already seen what we refer to as basic anatomy of a policy - all the pieces that go together and define your policy.
So, branching beyond the simple concept of "If / Then" statements, let’s break policy down into each part you can interact with keeping an eye on the editing screen for a policy displayed in Figure 3.5, “Editing a Policy and its Attributes”.
- Policy Name
- This name will be displayed on the Policy tab in the application composition report. Others will see this regularly, so it should be unique, clear, and concise.
- Threat Level
- A number, 10 - 0, that is color coded (red, orange, yellow, dark blue, and light blue), and represents the perceived severity if this policy is violated. The number will also be used to create the order in which policy violations are displayed.
- Constraints
-
Each policy must have at least one constraint. When a constraint is fulfilled, a policy violation occurs. A constraint itself consists of the Constraint Name and at least one condition. Make sure it clearly identifies the conditions that you have added for the Constraint.
- Conditions
- A condition is considered the if part of an if-then statement. There are a wide range of conditions possible, that have there own set of values you can choose from.
- Any/All
- Any/all is required when there are multiple conditions. This tells the policy whether all of the listed conditions, or simply any of them, must be met in order to have a policy violation.
- Actions
-
The "then" part of an if-then statement. The action chosen here will be taken when the policy constraint and its associated conditions have been met.
- Stage
- These stages represent the enforcement point. They are Procure, Develop, Build, Stage Release, Release and Operate.
- Warn and Fail
- Each enforcement point for each stage can be configured to cause a *Warn*ing or a *Fail*ure.
- Custom
- This action allows you to select an email, or emails, to send notification to when new policy violations have occurred.
Now that we understand the different attributes of an individual policy, you’re likely eager to create your own policy. We’ll tackle that next in Section 3.5, “Policy Management”, but first let’s take a look at some important items to consider when developing our policy.
Note
When viewing policy violations counts, please keep in mind that despite the number of constraints fulfilled, only one policy violation is counted.
To establish an understanding of risk within the context of CLM, we need to identify the various avenues of risk a component can have. The most common are security, licensing and architectural considerations.
Of course, we shouldn’t limit our thinking to these three alone, and in the long term you will define those specific to your organization. However, they will serve us well to get started.
When creating CLM policies, we need to consider what is the risk we want reported and how we want it reported. Take a look at these very simple example policies, one each for licensing, security, and architecture.
- Licensing
-
- Don’t allow distributed code to have GPL
- Only allow GPL that has a Commercial license
- Security
-
- Don’t allow components with a CVSS score > 7
- Architecture
-
- Don’t allow components that are older than 5 years
- Don’t allow Struts version 2.3.15.1
The above policies represent an organizational intent to not allow GPL highly insecure components. It further qualifies that old components and a specific version of struts are not to be used. In this way, our three policies are actually working together to form and overall policy approach.
As you move on to create your own policies, it becomes very important to think about how policies can build upon each other. In many ways this is a holistic approach, something that rules simply can’t do.
Policy development should be treated to be as important as any other aspect of Sonatype CLM. While it is more of the planning and thinking stage of policy, it can make the difference between well thought out and applicable policies and policies that require constant change, or seem to disrupt rather than compliment the development life cycle. Soon you’ll be creating policies on your own. For now though, be sure you take these key items away in this section:
- Importance of Policy Development
- Risk and Organizational Intent