Waiver Concepts
Table of Contents
- Understanding Waiver Scopes
- Example of Waiver Scoping
- What are Stale and Expired Waivers?
- Troubleshooting Waiver Issues
Understanding Waiver Scopes
When it comes to 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.
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 a 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.
Examples 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 Selection | Component Field Selection | Waiver Expiration Selection | Results |
|---|---|---|---|
| Application | example: example-component 1:12 | 7 Days | The Security-Critical policy is waived for example: example-component 1:12 in this application. No other components are affected. The waiver will expire after 7 days. |
| Application | example: example-component (all versions) | 7 Days | The Security-Critical policy 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. |
| Organization | example: example-component 1:12 | 7 Days | The Security-Critical policy 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. |
| Organization | example: example-component (all versions) | 7 Days | The Security-Critical policy 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 Organization | example: example-component 1:12 | 7 Days | The Security-Critical policy 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 Organization | example: example-component (all versions) | 7 Days | The Security-Critical policy 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. |
| Application | All Components | 7 Days | The Security-Critical policy is waived for every component in this application. The waiver will expire after 7 days. |
| Organization | All Components | 7 Days | The Security-Critical policy is waived for every component for every application in this Organization. The waiver will expire after 7 days. |
| Root Organization | All Components | 7 Days | The Security-Critical policy is waived for every component for every application known to the IQ Server. The waiver will expire after 7 days. |
| Application | example: example-component 1:12 | Never | The Security-Critical policy 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. |
What are Stale and Expired Waivers?
Stale Waivers
A waiver is considered Stale if there are no components that currently fall within its scope. A Stale waiver is still active. It will be applied when a policy evaluation detects a newly introduced component that falls within its scope.
You can view stale waivers from the Waiver Dashboard or use the Stale Waivers REST API to obtain a list of stale waivers.
Expired Waivers
A waiver is considered Expired if it was scoped to only apply for a certain duration, and that duration has passed.
You can view all expired waivers from the Waiver Dashboard.
Troubleshooting Waiver Issues
A previously applied waiver is not applicable anymore.
- Check if the waiver has expired.
- Check if there is a change in the component version (but the violation still exists.)
- Waivers function in the context of a policy. It will cease to apply if any policy condition or constraint changes.
Examples:
- A waiver created on a security-high policy corresponding to a high CVSS score (7.5) will not be applied if the CVSS score is upgraded (>=9). A new waiver will have to be created for a security-critical policy corresponding to the upgraded CVSS score.
- A waiver created on a security-critical policy corresponding to a CVSS score (>=9) will not be applied if the CVSS score is downgraded (7.5). A new waiver will have to be created for a security-high policy corresponding to the downgraded CVSS score.