Creating overrides

Catalog standards ensure that only open source packages that meet your defined standards are approved in your catalog. However, there are cases when you may want to create an override for a package to be approved even if it doesn't meet the standards.

Examples of when you may need an override:

• Security Even though you are using a package release with a vulnerability, the package release is not being used in an exploitable way or using the package release is a risk that your team feels comfortable assuming.
• Licensing You have a package that is licensed with a license that you would typically deny, however in this instance it would be okay to approve the package despite the license. 
• Maintenance Although your organization has a standard to use non-deprecated packages, you may feel comfortable creating an override for a small or widely-used package.

Creating overrides for each standard

For each standard that's enabled for your catalog, you are able to manage its overrides:

Review security vulnerabilities When reviewing a security vulnerability, you may choose to Ignore the vulnerability for the affected package. This effectively creates an override and will keep the package release approved in your catalog.

License compliance When approving a new release with a non-compliant license, you may choose to only approve the license for that particular package or that particular release of the package.

You can view and export all of the license compliance overrides you created:

1. Go to Catalogs
2. Select Standards
3. Find the Allowed licenses standard
4. Click on manage overrides
5. From here you can add new, edit, and export as .csv.

Creating conditional overrides

Project-based or group-based overrides, or conditional overrides, can be given to previously-denied packages. These overrides will allow a package to be denied for the catalog, except for specific projects or groups. We recommend thinking deeply about the decision to apply conditional overrides, as doing so allows vulnerable software that doesn’t meet your standards to exist in your projects. It is better practice to deny a package and let the project fall out of alignment, so that it remains a constant reminder of the issue.

Some examples where you may choose to use a conditional override:

• A team, whose old application is soon to be sunsetted, has investigated a CVE and determined that the way in which the package is used leaves it not exploitable. The catalog administrator can choose to apply the override to this project. Only this project will be allowed to use this package, and their continued use will not negatively affect their project. Note: Alignment scores will still be affected as alignment relates to the number of packages approved in the catalog.
• An internal application is allowed to use different licenses as opposed to something distributed. A catalog administrator may choose to apply an override for one of these licenses for any projects deemed to be “Internal”. This will deny any packages with the license to be used in projects without the “Internal” group tag.

To create a conditional override for a security issue:

1. After running an alignment, your team notices one of the packages in their project is denied. They determine they should get an override as they have no intention of addressing the security issue.
2. A catalog admin can create a security override for the project or group(s) of projects from the latest alignment by clicking the Add security override button. A modal will appear, which allows you to associate the override with the project and/or any groups this project is associated with. This allows the project(s) in question to continue permitting use of a package that the team knows they have no priority, desire, or necessity to stop using.

For all types of conditional overrides

On each standards configuration page you can choose to View overrides. Similarly to adding a regular override you can create a new override. To create a conditional override, from the dropdown, select the project or groups that the override should apply to. Projects will start with "tidelift:project:" and groups will start with "tidelift:group:"

Once added, the Project label column will indicate the groups/projects this override applies to. An empty field indicates a non-conditional override.