Creating exceptions

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 exception for a package to be approved even if it doesn't meet the standards.

Examples of when you may need an exception:

• 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 exception for a small or widely-used package.

Creating exceptions for each standard

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

Review security vulnerabilities When reviewing a security vulnerability, you may choose to Ignore the vulnerability for the affected package. This effectively creates an exception 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 exceptions you created:

1. Go to Catalogs
2. Select Standards
3. Click on Configure standard under the Releases use approved licenses standard
4. Navigate to View exceptions on the right
5. From here you can add new, edit, and export as .csv.

Creating conditional exceptions

Project-based or group-based exceptions, or conditional exceptions, can be given to previously-denied packages. These exceptions 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 exceptions, 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 exception:

• 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 exception to this project. Only this project will be allowed to use this package, and their continued use will not negatively affect their project health. 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 exception 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 exception 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 exception as they have no intention of addressing the security issue.
2. A catalog admin can create a security exception for the project or group(s) of projects from the latest alignment by clicking the Add security exception button. A modal will appear, which allows you to associate the exception 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, without impacting their project health.

For all types of conditional exceptions

On each standards configuration page you can choose to View exceptions. Similarly to adding a regular exception you can create a new exception. To create a conditional exception, from the dropdown, select the project or groups that the exception 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 exception applies to. An empty field indicates a non-conditional exception.