Whenever a violation is found, Tidelift automatically decides if it is allowed or not allowed based on how you’ve configured your standards (your policies). In some cases you may wish to manually change this decision, and you can use overrides to do so. You can think of 'overrides' as policy exceptions.
Overrides always take precedence over the violation decisions automatically made by your standards, so while they can be helpful in a number of situations, you’ll want to use them carefully.
When to use overrides
Examples of when you may need an override:
- Your standards don’t allow high severity CVEs, but a particular high severity CVE doesn’t apply to how you’re using a package. You can create an override to allow the violation that the CVE is creating.
- Your standards don’t allow the use of deprecated packages, but a deprecated package you’re using doesn’t have a replacement and you’re willing to accept the risk of continuing to use it. You can create an override to allow the deprecation violation for that package.
Where to create an override
Overrides can be created in a few ways.
Release status drawer
When viewing releases for a package you can see which releases are approved and denied by your catalog. Clicking on the approved or denied label will open the release status drawer and show you any violations found. From this view, you can override one of the violations listed by clicking allow.
Standards page
All violations for a given standard can be managed by clicking the manage overrides button below the standard name in your standards configuration. The override management page allows you to create new overrides or view and delete existing ones.
Tasks
When you enable tasks for a particular standard, you’re telling Tidelift that you’d like to manually review violations for that standard. The way Tidelift tracks your manual decisions is through overrides. As each new violation creates a new task, you will need to manually click through the entire task flow and confirm that you agree with the auto-decision, or apply a new manual decision. In the background of this, Tidelift creates a corresponding override for your manually changed decision.
As a special case, if you do one task for a release, and confirm denial of that release, other tasks that are open only due to that release will also go away. This is because some releases can have dozens of vulnerabilities, and if you've already manually confirmed you don't want to use the release, there's no need to go through dozens more tasks.
API
In addition to the methods above, you can also create an override using Tidelift’s API.
Scope of overrides
Because violations represent various types of problems, not all violations have the same scope. For example, violations found by the allowed licenses standard can affect multiple packages because multiple packages can share the same problem of using a license that’s not allowed. In contrast, violations found by the prereleases standard only affect a single release of a single package.
This is important to keep in mind because sometimes you’ll be asked to provide the scope for which you want to apply an override. For example, if you want to override a particular security vulnerability from not allowed to allowed, you’ll be asked if you want to apply the override to a specific release or all current and future affected releases. Your choice could be the difference between saying the vulnerability should always be allowed versus saying the vulnerability should only be allowed for this specific release that’s currently in use.
Tidelift also allows you to create project and group-scoped overrides. This allows you to manually decide whether a violation is allowed or not allowed on a specific project (single application) or group (set of applications). For example, you might want to say that a particular project gets an exception on a particular vulnerability. This kind of override can only be created from the override management screen available from the standards configuration in your catalog.
Best practices
Tidelift offers you a number of ways to create overrides so that you can set the conditions for your policy exceptions in the way you need to. However, this flexibility means it’s easy to create complex sets of overrides that can be challenging to manage. To avoid this, here are some best practices for creating overrides.
- Avoid creating overrides in the first place. By their nature violations represent instances where your applications have issues that you’re trying to prevent. The best way to maintain a secure and healthy software supply chain is to keep your dependencies up to date (if there is a violation-free update available) or use better dependencies altogether. It's important to keep a consistent view of your policies for your developers to minimize operational overhead for the organization.
- Minimize the use of per-project overrides. It’s typically too much micromanagement for more organizations to keep up with. The motivation for wanting to do this usually relates to failing builds in CI unless they perfectly align to the catalog. Our experience is that continuous improvement in the quality of your dependencies is very possible, maybe even easier, without failing builds.
- Don’t manually create overrides that agree with your standards (both your override and your standard deny a specific violation). While this is technically possible to do, it only applies to standards where you’re using tasks, and if that’s the case, you should use the task workflow to complete the manual decision workflow instead.
Limitations
There are a number of things overrides cannot currently do.
- You cannot create an override for a range of releases. You need to create separate overrides for each specific release.
- You cannot create an override that allows all potential vulnerabilities for an entire package. All vulnerability overrides must contain a CVE ID to prevent you from inadvertently ignoring unknown future vulnerabilities.
- You cannot create an override that allows all violations for a particular package or release. Overrides only apply to violations, not packages or releases.
- You cannot create an override that prevents the use of a particular package or release regardless of potential violations. To do this, you would block the package or release instead.
- You cannot set a future date to make an override take effect. It is only possible to make an override expire at a future date, which can be configured in all places you can create an override.
- You cannot create an override that takes into consideration multiple types of violations. Overrides can only apply to one type of violation at a time.
- You cannot edit an override. To edit an override it’s necessary to create a new one. If a new override 100% contradicts an older one, the older one will be automatically deleted. If a new override only partially contradicts an older one, both continue to exist but the more specific one applies when determining the allowed/denied status of a particular release.
These limitations are in place in order to ensure a complete record of when violations were first detected, and what happened next. This provides our customers with the peace of mind needed for any later auditing.