First of all, let’s talk about what a waiver is in regards to IQ Server policy. Waivers are a feature within Nexus Lifecycle that let you accept risk for a given policy violation. They are meant as a means to help organizations accept risk for the time being when there are no possible, or acceptable, upgrades for a violating component. Waivers are commonly used as a way to provide teams with time to review and upgrade vulnerable components.
If there is a vulnerable component that doesn’t pass policy, there are three options for mitigation:
- Upgrade to a non-vulnerable version.
- Find a new component that doesn’t break policy.
- Apply for a waiver.
By adding a waiver, you indicate that a particular violation, either in the scope of an application, or all applications for the organization, is waived from a particular policy. The rules that shape the waiver can be scoped at many different levels—the specific Application, the Organization, or the Root Organization—and can apply to either a specific component or all components.
Recently, the IQ Server team has released a series of waiver enhancements designed to help you define, apply, and manage waivers:
- Add waiver page: The creation of the new Add Waiver page now extracts the waiver experience from the report itself by placing the capability within its own space that can be accessed from both the Application Scan Report and the new Violation Details page.
- Time-based waivers: This new feature offers the users the ability to apply a time component to a given waived policy violation that would auto-deprecate after the allotted time frame.
- Manage Waivers for Violation: This new page is accessible from the Violation Details page for any policy violation that has a waiver. This new page provides users the ability to begin evaluating the number of waivers in existence for a given policy violation. From here, you can see which waivers have been created, what their scope is, and how many are active, stale, or expired. You can also delete or create a waiver from this new page.
Next up, we’ll walk through an example use case that shows you why you would want to apply for a waiver, and how to go about this with our enhanced waiver workflow.
Example Use Case
In this example, we’ll walk through two parts of the waiver process: (1) how a developer could determine that a waiver should be applied, and then (2) how the application owner could then add and manage waivers.
First up, let’s walk through the determination process:
- James, the developer, is assigned a Jira ticket showing all policy violations for a component.
- James researches the violation, and sees that Lifecycle recommends finding a new component, as there is no non-vulnerable upgrade path for this component/package.
- Due to this, James decides to request a waiver that will expire in one month, giving him bandwidth to find a new component.
- James updates the Jira ticket with the information required to complete the waiver request, which includes:
- The application name of the policy violation
- The policy and issue being violated
- The specific component to be waived
- Waiver expiration date
- The justification for the waiver
- James then assigns the ticket to the owner of the application who has been assigned rights to accept the risk of waiving the violation.
Next, we’ll show you how to apply the waiver:
- Ana, the application owner, sees that she has a Jira ticket assigned to her with a waiver request.
- She opens the ticket and sees that James has done his research, and supplied her with plenty of information to approve and apply the waiver.
- Ana logs into Lifecycle, goes to the Dashboard, and filters for the Payment-App to find the policy violation for that component.
- She accesses the Violation Details page for this component, and then selects the Manage Waivers button.
- In the Manage Waivers for Violation page, she can review the violation details and applicable waivers.
- She then selects the Add Waiver button to access the Add Waiver screen.
- Ana uses the information supplied to her from James to scope the waiver to the specific application and component, sets the waiver to expire in 30 days, and clicks Submit.
Over the next month, James finds a non-vulnerable component that works in his application. He then completes his unit and integration tests and sees that the build is no longer breaking policy. He updates the Jira ticket and lets Ana know that all is good, and the waiver can go ahead and expire in the next couple of days. Ana logs into Lifecycle, accesses the Manage Waivers for Violation screen, and sees that the waiver has expired, and she closes the Jira ticket.
You’ve seen how a development team can determine a waiver is necessary, apply the waiver, and then manage their waivers. Now, we’ll provide you with some best practices for using waivers in Lifecycle.
Some Best Practices
Below are some best practices the Sonatype Customer Success organization has identified. We will add more to this list as they are identified.
When to apply for a waiver
By adding a waiver, you indicate that a particular component, either in the scope of an application, or all applications for the organization, is waived from a particular policy.
Ideally waivers should not be considered permanent fixes, but rather acceptance of risk. The violations don’t go away just because the waiver has been added. This is why time-based waivers should be used as often as possible so they are regularly reviewed to still be applicable.
Remember that it is better to remediate the violation rather than waive them. Check out our Advanced Development Pack for even more features that help you pick better components.
Keep the scope of waivers as narrow and short as possible. The option to waive all components or all applications can have negative consequences if the risks associated with them are not understood.
Use the Advanced Search option to understand which applications are affected by a common violation before applying a wider-scoped waiver.
Talk to Us
And visit my.sonatype.com for all things Sonatype.