Creating overrides

Whenever a violation is found, Tidelift automatically decides if it is allowed or not allowed based on how you’ve configured your standards. In some cases you may wish to manually change this decision, and you can use overrides to do so.

Overrides always take precedent 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 that CVE.
  • 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.




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, therefore, for each task you complete, Tidelift creates a corresponding override.



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.
  • 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 requiring builds to be completely violation-free.
  • 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 make a manual decision instead.


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.

Was this article helpful?
0 out of 0 found this helpful



Article is closed for comments.

Articles in this section

See more