Waivers
Waivers are used to temporarily accept a specific risk when depending on an open-source component in your application to resolve the associated policy violation. Waiving a violation does not make your application more secure nor will it remediate the violation. Waiving will resolve the violation in the application report and keep the violation from triggering policy actions.
Waiving the violation meets the following use cases:
Use case | Example and Recommendation |
|---|---|
Resolve build-failing violations by deferring the fix until a remediation path forward is available | Example: a fixed version for a critical vulnerability will not be out for another 2 weeks however we need to release the application now. Recommendation: apply waiver scoped to 2-3 weeks with a link to the coming fix. |
Annotate the risk with developer feedback as to the violation's reachability and impact | Example: development concludes that the violation is not applicable since the vulnerable code is not used by the application Recommendation: apply the waiver scoped to 6-12 months to review the violation is still not applicable. Upgrade to a non-vulnerable version when available. |
Reduce the noise of violations that will not be prioritized by the development team | Example: the development team does not have the capacity to resolve the issue at this time. Recommendation: apply a waivers scoped to the next sprint or quarter. Add a ticket to the team's backlog to timebox for a future sprint. |
Scope common remediation steps more broadly across the organization | Example: a common library with a new violation is breaking many builds across the organization. Recommendation: quickly apply a temporary waiver scoped to the organization. Use the advanced search to find all applications with the component and add tickets to each application team's backlog. Set expectations on when the issue must be resolved so teams have time to address the issue. |
Inform stakeholders of the team's approach to addressing the risk | Example: the violation is resolved with code changes however the component is not being replaced. Recommendation: Add a waiver scoped to 12 months with details on how the component is used and fixed. Regularly review these fixes and upgrade the component when a non-vulnerable version is available. |
Use as a workflow tool to manage, prioritize, and audit policy violations | Example: A large number of violations on the application report confuse the development team and they don't know where to begin. Recommendation: Use Legacy Violations to hide the non-critical violations and waive violations to be done at another time. |
Waivers and Repository Firewall Quarantine
Using Repository Firewall, components with policy violations set to fail are put into a quarantine to keep them from being downloaded during an application build. Waivers are used to release components by waiving all the failing violations against the component. Once the component has been allowed into the repository, failing violations will not put the component back into quarantine.
In some use-cases, you may want to release a component from quarantine but still trigger policy violations where they are found in applications during a Lifecycle analysis. The waivers used to release the component should be scoped to either only the repository from which they were quarantined or using a short lived time-based waiver. Once the waiver expires, the component will again trigger the violation. However, since it is already in the repository, it will not be quarantined.
To quarantine the component again, delete it from the proxy after the waivers have expired or remove the waiver before attempting to download it again.
Waivers and Legacy Violations
Legacy Violations are an effective way to accept a base level of risk without a detailed review of the violations. They are configured at the policy level and apply directly to all violations in an application as a single configuration. This feature is useful for legacy applications not in active development to only prioritize newly discovered risks. Violations that are hidden by legacy violations may be reviewed and addressed without disabling legacy violations for the application.
Waivers are applied to the specific metadata associated with component violations. They are intended to provide granular control and violation management. Consider using legacy violations instead of applying bulk waivers to all violations especially when they have not been reviewed by the development team.
Waiver Properties
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.
Internal Hierarchy
Waivers can be scoped to any level of your applications and organization's hierarchy. 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, and 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.
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 when scoped to a certain duration and that duration has passed.
You can view all expired waivers from the Waiver Dashboard.
Firewall Waivers
To release a component from quarantine you must waive the failing policy violations. Components are automatically released from quarantine when the failing violations are no longer open.
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 findings based on Sonatype data
The stage (CI/CD) to which the policy is applied
Specification of whether it can be inherited or overridden
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.