Vulnerability suppressions

Apollo supports a suppression system to prevent Apollo from recalling Product Releases with vulnerabilities.

There are two types of suppressions:

• Human requested suppression: Suppressions that you can create in Apollo.
• Grace period suppressions: Grace periods are the maximum amount of time before a CVE must be addressed or the affected Release will be recalled. Grace periods begin when a vulnerability is originally discovered and not when a vulnerability scan runs.

You can view vulnerability suppressions in the Risk Management application. Select Risk Management from the Applications menu in the left sidebar.

The Suppressions tab displays all the active suppressions for vulnerabilities.

Creating vulnerability suppressions

Select a particular vulnerability from the Vulnerabilities tab of the Risk Management application. Then select Suppress this vulnerability from the Remediate dropdown.

This will open the suppression creation form.

First, you should choose a suppression scope. This defines what Apollo resources the suppression will be applied to. We recommend choosing the most granular option possible.

Suppress by Image is the recommended suppression scope. You can provide information about the container image for which findings of this vulnerability should be suppressed. This is the most preferred and most granular way to suppress vulnerabilities. It ensures that these suppressions still apply to vulnerability scans for Product Releases that have yet to be published.

You can select Advanced options to choose another suppression scope.

• Suppress by Image Prefix: There may be multiple related container images that are affected by the same underlying vulnerability. This typically happens when they come from the same open source software component, where the findings are related by code repository. In this case, you can suppress the vulnerability by prefix instead. Where possible, you should suppress vulnerabilities by image instead.
• Suppress by Distribution: Use this when you trying to suppress vulnerabilities for published SLS distributions of your products, in addition to or instead of container images. Non-containerized products can also contain vulnerable software components that will be identified by a vulnerability scan. This option will have no effect for container images.
• Suppress Globally: Ignore a specific vulnerability whenever it is identified in a vulnerability scan. This is an exceptional case where there is a problem in the scanner or in some upstream database.

Although you are suppressing vulnerability findings, future scans will continue to detect them. The suppression category is how you describe why it is acceptable that future scans yield the same vulnerability findings past their grace period.

There are three options for suppression category:

• False alarm: Use this category when the findings are not accurate. This is often because data has been incorrectly recorded in upstream databases and the ranges of vulnerable components are not accurate. You should record specific references that help prove that your software does not have this vulnerability. Note that if the vulnerability does exist, but you have mitigated it in some way, you should use the Won't Fix category instead.
• Won't fix: Use this category when you cannot remove a vulnerable software component, but you have mitigating controls in your software that protect against the vulnerability. It is important to document the mitigating controls and how they protect against threats imposed by the vulnerability. You should seek to remove vulnerable software components altogether, rather than suppressing findings.
• Vendor dependency: Use this category when a vulnerability is present in an upstream software component that is a key dependency of your Product. You should seek to upgrade to new versions that are not vulnerable or to remove the dependency instead. You should document specific references to reported issues against these upstream software components flagging the vulnerabilities for the vendor to fix. You should revisit these vulnerabilities as the suppression expires to determine if a new fix is available or to re-think the dependency altogether.

Next, enter a reason for suppressing this vulnerability. You should include information that will help other users understand why you want to prevent Apollo from recalling the affected Release(s).

Lastly, you should specify an expiration date for the suppression. after this date, the vulnerability will be active again. You can choose one of the suggested dates or enter a custom date.

Select Create suppression when you are finished. This will create a change request. To configure who can approve suppression change requests, navigate to the Settings & Configuration page from the main Apollo sidebar, then select the Permissions tab, and grant the Approver role under Vulnerability suppressions. Once it is approved, the suppression will be applied to the Release on the next vulnerability scan.

Removing vulnerability suppressions

To remove one or more suppressions, navigate to the Suppressions tab of the Risk Management application, check the suppression(s), and select Remove suppressions. This will create a change request.