Fine Grained Waivers

Understanding Waivers


Fine Grained Waivers were introduced with the Nexus IQ Server 53 release. Earlier versions took a broader approach to applying waivers. If you haven't already, update your IQ Server today.

This page discusses how Waivers work and how to configure them to suit your project's needs. For a more general explanation on how to add, view, and remove waivers, visit this documentation.

Waivers are a feature of IQ Server and Lifecycle that allow users to accept components with policy violations. You'll use waivers in one of two situations:

  • When you must accept the risk brought in by a component in the context of your application
  • When a policy violation doesn't make sense in the context of your application, e.g. a license policy violation in a component that will only be used internally

Good waiver usage reduces noise and, if you're integrating Lifecycle with your CI/CD tools, can prevent unexpected build failures.

But there's some nuance to how waivers work. They're fine-grained, and scope to a number of parameters, some of which you set during the waiver creation process, and some of which you don't control.

Waiver Parameters

Seen below is an example of the Add Waiver page. It's a useful visual aid for understanding how Waivers are configured.

Conditions and Constraints

Conditions and constraints are the foundation of every policy, so they're also the key to understanding waivers. A condition is an if/then statement, and a constraint is a container for a collection of conditions. If the conditions within a constraint are satisfied, then the containing constraint is satisfied. Multiple constraints inside a policy are combined with OR. Therefore, a policy is violated if any one constraint in that policy is violated.

When you create and apply waivers, what you're waiving is the specific constraint/condition combination, as shown on the Add Waiver page. This has some implications that you need to understand.

  • Imagine a security policy with one constraint and one condition. If a component satisfies the condition five times, then the policy has been violated five times.
    • If you want to remove the policy violation from the report, you'll need five different waivers. This is a non-trivial level of administrative debt. Accepting the risk from such a vulnerable component is unwise.
    • If you find yourself in this situation, review the component in question and look for remediation options, like upgrading to a newer, less vulnerable version. If remediation isn't possible and waivers must be used, then use the comment box to thoroughly document the situation.
  • Imagine a policy with one constraint that has two conditions. If you create a waiver for that constraint, you're waiving both conditions. This may be undesireable.
    • In this situation, review your policy set and ensure that your policies are configured in a way that makes sense for your project and organization. It may be wise to seperate this one policy with one constraint and two conditions into two policies, each with one constraint and one condition, which will give you more precision when creating and applying waivers.
  • You can't alter the constraint/condition combination from the Add Waiver screen. If you have a combination that you need to waive, find a policy violation that matches, click the policy violation, and open the Add Waiver screen from there. If you're looking to premptively waive a violation, it's probably best to review your policy set instead. See the Other Methods of Removing Violations from your Reports section below for more guidance.

Scope/Internal Hierarchy

Waivers can be scoped to the same hierarchy that IQ Server uses elsewhere. If you select Application, then the waiver will be applied for just the currently selected application. This is the smallest scope possible.

Selecting Organization will apply the waiver to all applications under the organization, and selecting Root Organization will apply the waiver to all organizations and all applications under them. These are wider scopes, and applying the waiver so broadly may not be desirable because it could leave you unaware to critical risks in other applications.

Components

Usually, you'll choose to apply the waiver to only the named component – the same component whose violation you clicked on to bring you to this page. You can also choose to waive this constraint/condition combination across all components at the scope you selected in the section above.

However, if you find yourself applying waivers like this frequently, consider revisiting your policy set and making adjustments instead of applying waviers. If every component with the same constraint/condition combination requires a waiver, then the policy set is essentially generating false positives, and it's likley generating a lot of noise for your Security and Development teams. Waivers are so fine-grained that trying to reduce this noise with waivers will create a lot of administrative debt. Adjusting your policy set to elminate the false positives is the better solution.

Ask yourself this:

  • Does my use-case require a record that a risk was deemed acceptable across all components in an application? If yes, use a waiver.
  • Is there a threat that no one will remember that policy for this application was adjusted? Will the policy set for this application be used as a template for other applications? If yes, use a waiver.
  • Am I frequently applying broad waivers to components in this application? If yes, adjust the policy set.
  • Do all the violations I waive for this application make no sense in context? If yes, adjust the policy set.

Expiration

Waivers can be set to expire after a certain period has elapsed or to never expire. As a best-practice, if a violation is blocking an urgent build, but the component will need remediated eventually, set the waiver to expire after 7 days.

Other Methods of Removing Violations from your Reports

Waivers are powerful but nuanced, and their primary purpose is to let you accept the risk of policy violations and reduce noise. But if your goal is just to reduce the number of policy violations in your reports, then waivers are too fine-grained to serve your purpose.

  1. The best, safest, and most future-proof way to remove policy violations is to remediate bad components. Removing a policy violation from a report in any other manner doesn't make your application safer or less exploitable. If you're frequently waiving the same components, prompt your developers to use the IDE integrations or Chrome plugin to inspect components early. Use the remediation information from the Component Details Page to learn how a bad component can be remediated – usually, the best path is to upgrade to a non-vulnerable version of the same component.
  2. Policy can be configured to block builds in the CI/CD tools you use. Waivers can help reduce the number of blocked builds when they're used effectively, but if it doesn't make sense to block a build because of a policy violation, then don't use waivers to solve that problem. Instead, adjust the policy to not fail builds.
  3. If every violation makes no sense in the context of a specific application, then adjust the policy set to better reflect the goals of the app. For example, if an internal app has a single license-based violation, then a single waiver that will never expire is probably the best choice. But if an internal app has dozens or license-based violations, then adjust policy to refelect the fact that license concerns won't introduce any risk.
  4. If the first scan of an application reveals policy violations that aren't an immediate priority, Grandfathering can remove those violations from the report until you're ready to deal with them. This immediately reduces noise, prevents overwhelming your developers, and reduces the friction of onboarding new applications.