If you look at policy violations as a pain point preempting the flow of work, you are likely going about your evaluations and policy in 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 of 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, there are no false positives when it comes to policy violations. If you are looking for ways just to get past a violation, you’ve circumvented the goal of policy creation. Why not simply not make it a policy? Better yet, this might be a problem with policy, or the perception of what should and should not be in your application.

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.

Use Case for Waivers

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 with 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 condition, 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 the 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.

Adding a Waiver

Waivers can also be added from the Waivers for Violation page.

  1. Access an Application Composition Report.
  2. In the Policy Violations Table, click on a component that has policy violations. This displays the Component Information Panel (CIP).
  3. In the CIP, click the Policy Violations tab. This displays the list of Policy Violations for the Component:

  4. Click the Waive button next to the violation you wish to waive. The Add Waiver Page displays:
  5. There are two options at this point, and each should be carefully considered:
    1. The first option defines the scope for the waiver. This can be either the current application or all applications for the organization, or even the root organization.
    2. The second option defines the target of the waiver. That is the currently selected component or all components.
    3. The third option is the Waiver Expiration dropdown. Choosing an option different than "Never" will create an expiring waiver — Expiring waivers expire at End of Day (11:59:59pm) of the day when the count is completed. All times are calculated using the user's local time.
  6. Enter an optional Comment, and then click the Submit button to process the waiver.

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.

Requesting a Waiver to be Added

Requesting a waiver can be used for workflows that require review and approval for waiving violations. The Policy Violation ID along with a sample curl command can be found in the Request Waiver Dialog and should be shared with the approver.  A comment is optional when adding the waiver.  Learn about automating waiver requests using our Policy Waiver REST API - v2.

  1. Access an Application Composition Report.
  2. In the Policy Violations Table, click on a component that has policy violations. This displays the Component Information Panel (CIP).
  3. In the CIP, click the Policy Violations tab. This displays the list of Policy Violations for the Component:
  4. Click the Request button next to the violation you wish to waive. A dialog displays:
  5. Send the information from the dialog to an approver with permission to carry out the waiver using the details in the dialog, such as Policy Violation ID and/or the CURL Example.

Viewing and Removing a Waiver

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 of 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:

  1. Access an Application Composition Report.
  2. In the filter section of the report, you will see the Aggregation by Component toggle and the Violation State filter:
  3. Disable aggregation by component. 
  4. Expand the Violation State filter and select the "Waived" checkbox.
  1. Click on a component to display the Component Information Panel (CIP), and navigate to the Policy Tab
  2. At the top of the component list, click on the View Existing Waivers button. A modal displays showing all the waivers for the component, as well as the associated descriptions.

    To remove a waiver:

  3. Click the remove icon (  ):
  4. A message asks you to confirm this removal. Click the Remove button to continue.

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.