Optimized Component Lifecycle Management with Sonatype CLM
If you look at policy violations as a pain point preempting the flow of work, you are likely going about using Sonatype CLM the wrong way. In fact, if you saw the title of this section, hoping to find a way past policy violations, there may be a couple issues.
First, your policies should be designed to encourage workflow and communication. If development is being stopped regularly, you might want to revisit your policies, refining them so they present the possibilities for making better choices, not simply halting work altogether.
Second, and perhaps most importantly, Sonatype CLM does not present false positives. If you are looking for ways just to get past a violation, you’ve circumvented the goal of policy creation as well as Sonatype CLM. Again, this might be a problem with policy, or the perception of what should and should not be in your application.
OK, so excluding those possibilities, and working with the idea that you are here to find a way to accommodate the exceptions you may run across, waivers can help.
Let’s say, you have a component that’s violating a policy, which has been created in an organization that houses your application. It’s a great policy, in fact, one of many great policies. Unfortunately, one of your applications has a component that is violating a policy.
The problem is, that this policy just doesn’t accurately line up to the implementation of this particular application. Your application has a security vulnerability that can be exploited when it connects to the internet. It’s a pretty severe vulnerability, but benign given that your application is internal, and doesn’t even have the ability to connect to the Internet.
What should you do?
You could…
- Change the Security Status to Not Applicable.
- Adjust the policy to be less stringent.
- Use labels in a conditions, providing an escape for exceptions.
- … or, you could add a waiver.
That is, by adding a waiver, you indicate that this particular component, either in the scope of this application (what we would do in our example), or all applications for the organization, is waived from this particular policy. In fact, if you desired you could even specify that you want to waive all components (within scope of an application or organization) from a policy.
Now the important thing to take note of here, is that while this waiver seems to be the answer to policy violations strife, you are actually waiving an entire policy. This means all constraints, and in turn, all conditions. It’s no surprise why that should be something that’s limited. For this reason, before waiving something, it’s good practice to review some alternatives. A waiver very much does allow you to simply bypass all controls.
OK, we’ve harped enough on the warnings. The benefits of waivers can be just as numerous. This is because even with endless customizations, you will encounter situations where a policy just doesn’t apply. It’s important to take a look at the full range of waiver functionality, so let’s look at how to add, view, and when necessary, remove a waiver.
- Access an application composition report.
- Navigate to the Policy tab on the report, and click on a component that has policy violations. This will display the Component Information Panel (CIP).
- Click the Policy tab. This will display the list of Policy Violations for the Component visible in Figure 4.38, “Waiver Button”.
- Click the Waive button next to the violation you wish to waive. A modal dialog similar to Figure 4.39, “Options to Apply Waiver to the Application or the Entire Organization” will display.
-
There are several options at this point, and each should be carefully considered:
- The first option defines the scope for the waiver. This can be either the current application, or all applications for the organization.
- The second option defines the target of the waiver. That is the currently selected component, or all components.
- Enter an optional Comment, and then click the Yes button to process the waiver.
Warning
When processing a waiver, depending on the options that are chosen, you can effectively waive a policy for all components, for all applications in an organization. Since this will waive the entire policy, not just this violation, it may be a good idea to ensure adjusting the policy would not provide a solution that is more visible to all users.
As we mentioned previously, component violations can be waived for a single component in a single application, all the way up to all components in all applications. This means, that a violation for a component in your application could have been waived elsewhere. A good practice when reviewing the Application Composition Report is to check and see what violations have been waived for components in your application. Here are a couple examples of why this is important:
- Scenario 1: A violation for a component has been waived, and the component has additional violations. Depending on the view selected, at least one of these additional violations will be displayed.
- Scenario 2: The only violation for a component has been waived. Given that the component has no additional violations, it will be moved into the None policy threat group (light blue) in the Summary view, while the other views will only show the waived violation.
To view waived violations for your components, follow the instruction below.
- First, access an application composition report.
-
Navigate to the Policy tab on the report. Just above the list of components, and to the right of the report, you will see three options in the Violations filter:
- Summary - this is the default view of the Policy tab. It is important to note, that even though this view will display all components, only the highest threat violation per component is displayed. In this view, components with waived violations may have been moved to the None policy threat group (light blue).
- All - clicking this filter option will display every violation for all components in your application. This may result in the appearance of duplicates in the component list. Violations that have been waived will be indicated by a white flag icon.
- Waived - clicking this filter option will display only the waived violations. In this view, you will only see those components where violations have been waived. Each component will have a white flag icon, and it is likely you will not see all components. This view may also produce the appearance of duplicated components.
- Click on a component to display the Component Information Panel (CIP). For an example, see Figure 4.38, “Waiver Button”.
- At the top of the of the component list, click on the View Existing Waivers button. A modal will be displayed showing all the waivers for the component, as well as the associated descriptions.
- Click the remove icon, which resembles a minus sign.
- A message will ask you to confirm this removal. Click the Remove button to continue.
Note
Because some waivers can be set for all applications, and even all components, it’s important to understand the impact of removing a waiver. Be sure to verify with the application or organization owner, the intended scope of the waiver.
If anything can be said, the ability to apply a waiver is easy. That ease can make them dangerous, but is also their source of power. It’s important to respect the ability to waive violations. This helps ensure they will serve as a tool in assisting to make your applications the best they can be. Let’s take a look at what we covered.
- Reasoning for using, as well as not using, waivers.
- Adding, viewing, and removing waivers