Waiver Best Practices

Waivers remove the open violations from your scan report by accepting the risk of the violation. While this can be an effective remediation strategy, it still leaves you vulnerable to potential risk.

Here are a number of best practices that will help you use waivers responsibly, reduce friction, and control your overall risk posture.

Waivers don't eliminate risk. Prioritize remediating risk by picking better components.

Tip

Waivers are a key part of the concepts of component risk and remediation. Learn more about the topics at the resources below.

• Definitive Guide to Open Source Component Best Practices
• What is Component Security Risk?
• What is Component License Risk?
• What is Component Quality Risk?

Scope your waivers narrowly by default

• Limit waivers to the application level for the violating component
• Use the Advanced Search or the Dashboard to understand the impact a waiver will have before broadening the scope

Use time-based waivers

• Avoid creating waivers with no expiration date
• Scope your waivers to as short of a time frame as makes sense.
• You may wish to adjust the time frame depending on the violation threat level.

Waive violations that cannot be remediated

• Avoid developers ignoring scan reports by temporarily waiving violations that cannot be remediated in the near term.
• Set an appropriate amount of time for the technical debt to be budgeted into development.

Review that the waiver validation is still appropriate

• Waiving violations is valid when your application is not at risk.
• Use time-based waivers to periodically review that this is still the case.
• Document both in the waiver and in internal wikis why your application is not at risk and why you should continue to use the component.
• If the project never plans to fix the issue, you will want to consider other projects.
• Your team may also wish to contribute back to the project to remove the issue.

Document the expected workflow for adding waivers

• At a minimum, the documentation should:
  • List stakeholders
  • Describe how waiver requests should be made
  • Set expectations on how long a waiver request will take
  • Outline default waiver values

Document who is responsible for granting waiver requests

• This is typically the project owner, AppSec, or Legal team members. Maybe a lead developer.
• Generally, you do not want to give developers the right to waive their violations.
• The person granting waivers will ultimately hold the responsibility for the risk.

Set guidelines on the violations allowed to be waived

• Some risks are so severe that they must be remediated and not be waived.
• Make sure those delineations are clearly documented so that developers are aware.
• Have discussions that include policy creators, risk owners, and developers.
• These sorts of discussions build your organization's DevSecOps maturity.