Waivers
What Are Waivers?
Waivers are a feature of Sonatype Lifecycle and Repository Firewall that prevents certain components from being flagged in scans. They are used when you decide to accept the risk of a policy violation.
It's important to understand that waivers don't make your applications more secure, more stable, or better designed. They also don't eliminate licensing concerns. They simply give you a way to formally accept the risk brought in by a component.
Waiver Use Cases
You'll use waivers when you decide to accept the risk reported in the context of your application. This might be necessary if there is no path forward for a violating component, meaning it can't be updated, switched out, or fixed. Accepting the risk could also be necessary if there's no priority to remediate the issue. For example, remediating the app could be outside the budget, or the app could be a legacy app that won't receive any further development.
You'll also use waivers when a violation can't or doesn't impact your application because of the specific context. For example:
- Your application has a license policy violation, but the application will only be used internally, so the licensing issue doesn't apply
- Your application has an architectural policy violation, but it's a legacy app and the violating component won't or can't be removed
- Your application has a security policy violation, but you've resolved the vulnerability elsewhere in your app
Finally, you'll use waivers when you intend to remediate or otherwise handle a violation but require more time and bandwidth to do so. For example, a developer may estimate that switching out a vulnerable component for a non-vulnerable component will take two weeks. In this scenario, you may choose to waive the violation for two weeks, which both removes the violation from reports during that period (improving the signal-to-noise ratio) and creates a record of the remediation effort that can integrate with your issue-tracking solutions.
Waiver Benefits
Good waiver usage has three primary benefits.
- Improves the signal-to-noise ration of your reports
- Serves as a record of risk that was accepted (and by extension, not accepted)
- Creates a DevOps-focused avenue for discussion between developers and the individuals with waiving privileges
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 Root Organization will apply the waiver to all organizations and applications under them. Selecting Organization will apply the waiver to all organizations and applications under the selected organization. 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
Issue: A previously applied waiver is not applicable anymore
Possible cause: Change detected in any element of the policy.
A "Policy" consists of:
- A set of conditions, constraints and facts*
- The stage (CI/CD) to which the policy is applied
- Specification whether it can be inherited or overridden
*Facts are findings based on Sonatype data, like the severity score of a vulnerability.
Over the course of time, if any or all of the above conditions change, Lifecycle detects this as a change in policy and a previously applied waiver will not be applicable. This "zero-tolerance to risk" built into Lifecycle ensures that users re-evaluate their need for a waiver and create one only if needed, based on the change.
Example: A waiver created on a policy with constraint/conditions for a security vulnerability of severity score of 6.5 will not be applicable if the severity score of the vulnerability changes i.e. goes down to 5.8 or goes up to 7. A new waiver will have to be created.