Overview of Suppressing or Unsuppressing a Vulnerability at the Project Level

For various reasons, your site might want to suppress—that is, hide—a security vulnerability that is associated with a specific component version used by inventory in a specific project. For example, maybe you have taken remedial steps to protect your code against the vulnerability. Perhaps the vulnerability affects a part of the component code not used in the product reflected by the project. Or maybe the vulnerability has proven to be a “false positive” (that is, incorrectly associated with a component version).

Any vulnerability can be suppressed—including a custom vulnerability, a vulnerability reported in scan results, or a vulnerability detected during an Electronic Update or the daily Library Refresh (and for which an alert is generated in your project). When you suppress a vulnerability at the project level, you must provide an exclusion analysis of the vulnerability in VEX (Vulnerability Exploitation eXchange) terminology. Basically, the exclusion analysis is an assessment of the impact and exploitability of the vulnerability within the context of your product. This analysis can be used to justify (or not justify) suppressing the vulnerability.

If you choose to suppress the vulnerability, it is no longer reflected in the project or applied to inventory during future scans on the project.

Should you later determine that the suppressed vulnerability does impact your product code, you can unsuppress it at the project level so that it again visibly associated with you project.

For more information about security vulnerabilities in general and how Code Insight handles them, refer to Working with Security Vulnerabilities.