Waiver Concepts

Understanding Waiver Scopes

When it comes to actually building and applying a waiver, one of the first things you'll need to consider is the waiver's scope. A waiver's scope determines what it covers and how long it covers it for.

Waivers are intended to give you very precise control, so there are lots of ways to configure the scope. In this content, we explain scope parameters and give examples of how those parameters affect a waiver.

Below is an image of the Add Waiver popover. It's a useful visual aid for understanding how waivers are scoped.

Policy, Constraints, and Conditions

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. Conditions can be combined inside a constraint with ANY or ALL, and constraints can be combined inside a policy with OR. 

Waivers are scoped to a constraint/condition combination, and each waiver only covers a single combination. But components can violate the same policy more than once if they violate the same constraint more than once. What this means for you is that a single waiver may not remove all violations from a component.

This is an visual representation of a policy with a single constraint and a single condition. If the condition is true, then the constraint is violated, and the policy is violated.

This is a visual representation of a policy with a single constraint and two conditions. The conditions are combined with either ANY or ALL, as defined by you when the policy is created. If the conditions are combined by ANY, then the constraint is violated if either of the conditions are true. If the conditions are combined by ALL, then the constraint is violated if both of the conditions are true. If the constraint is violated, then the policy is violated.

This is a visual representation of a policy with two constraints, each with a single condition. The constraints are combined with OR. If either condition is true, then the containing constraint is violated. If either constraint is violated, then the policy is violated.

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 of critical risks in other applications.

Components

Waivers can be scoped to the named component, all versions of a component, and can also be scoped to all components at the chosen level of the internal hierarchy. As a best practice, default to waiving just single components.

Expiration

Waivers can be set to expire after a certain period has elapsed, or to never expire. Letting a waiver expire may prompt you to review the circumstances of the waiver, so as a best practice, default to short waiver durations.

Example of Waiver Scoping

Imagine that your application has a component called example: example-component 1:12 which contains a vulnerability CVE-20XX-1000 with a CVS of 10. There's a policy called Security-Critical with one constraint, and that constraint has one condition that reads "Security Vulnerability Severity greater than or equals 9."

Review the table below to see how the various scoping options would affect a waiver.

Scope Field SelectionComponent Field SelectionWaiver Expiration SelectionResults
Applicationexample: example-component 1:127 DaysCVE-20XX-1000 is waived for example: example-component 1:12 in this application. No other components are affected.
The waiver will expire after 7 days.
Applicationexample: example-component (all versions)7 DaysCVE-20XX-1000 is waived for example: example-component all versions (past, present, future) in this application. No other components are affected.
The waiver will expire after 7 days.
Organizationexample: example-component 1:127 DaysCVE-20XX-1000 is waived for example: example-component 1:12 for every application in this Organization. No other components are affected.
The waiver will expire after 7 days.
Organizationexample: example-component (all versions)7 DaysCVE-20XX-1000 is waived for example: example-component all versions (past, present, future) for every application in this Organization. No other components are affected.
The waiver will expire after 7 days.
Root Organizationexample: example-component 1:127 DaysCVE-20XX-1000 is waived for example: example-component 1:12 for every application known to the IQ Server. No other components are affected.
The waiver will expire after 7 days.
Root Organizationexample: example-component (all versions)7 DaysCVE-20XX-1000 is waived for example: example-component all versions (past, present, future) for every application known to the IQ Server. No other components are affected.
The waiver will expire after 7 days.
ApplicationAll Components7 DaysCVE-20XX-1000 is waived for every component in this application.
The waiver will expire after 7 days.
OrganizationAll Components7 DaysCVE-20XX-1000 is waived for every component for every application in this Organization.
The waiver will expire after 7 days.
Root OrganizationAll Components7 DaysCVE-20XX-1000 is waived for every component for every application known to the IQ Server.
The waiver will expire after 7 days.
Applicationexample: example-component 1:12NeverCVE-20XX-1000 is waived for example: example-component 1:12 in this application. No other components are affected.
The waiver will never expire, and will only stop applying if it's manually deleted.