Vulnerability Annotations & VEX
Anchore Enterprise lets you annotate vulnerabilities reported for container images to provide details regarding the true-positive or false-positive state of the vulnerability for the customer’s product.
Roles and Permissions
The ability to manage vulnerability annotation data is reserved for certain users, typically on
the application security team. This capability is protected via a new RBAC role vuln-annotator-editor, which includes
the permissions to create, edit, and delete vulnerability annotation data.
Users which have been conveyed an RBAC role that contains the ability to listImages (i.e. read-only), are also able
to view the vulnerability annotation data and generate VDR (Vulnerability Disclosure Report) and VEX (Vulnerability
Exploitability eXchange) data exports.
Applying Annotations
Vulnerability annotations can be applied by any user with the vuln-annotator-editor role via the UI or API. Vulnerability annotations consist of the Annotation Status value and, optionally, the rest of the fields that make up a complete Vulnerability Exploit Statement.
- Status
Not affected: No remediation or mitigation is required. The vulnerability does not affect the listed products.Affected: Actions are recommended by the author to remediate, mitigate, or otherwise address the vulnerability. The vulnerability affects the listed products.Fixed: The listed products contain fixes for the vulnerability.Under Investigation: The author of the VEX statement or other relevant parties are investigating and have not yet declared a final status. Expectation is that this will eventually be updated to one of the above status values.
- Status Notes: explain the status value with additional details.
- Justification
Component is Not Present: The vulnerable component is not included in the product.Vulnerable Code is Not Present: The vulnerable component is included in the product, but the vulnerable code is not present. Typically, this case occurs when source code is configured or built in a way that excludes the vulnerable code.Vulnerable Code Not in Execute Path: The vulnerable code (likely in the component) cannot be executed due to the way it is used by the product. Typically, this case occurs when the product includes the vulnerable code but does not call or otherwise use it.Vulnerable Code Cannot be Controlled by Adversary: The vulnerable code is present and used by the product, but cannot be controlled by an attacker to exploit the vulnerability.Inline Mitigation Already Exists: The product includes built-in protections or features that prevent exploitation of the vulnerability. These built-in protections cannot be subverted by the attacker and cannot be configured or disabled by the user. These mitigations completely prevent exploitation based on known attack vectors.Fix Not Planned: The vulnerability impacts the component, but there are no plans to fix it. Refer to the impact and/or action statement for more details.
- Impact Statement: Explain the status value if the justification is not provided.
- Action Statement: Explain what steps will be taken to remediate this true-positive vulnerability.
- Analysis First Issued: When the exploitability statement was initially issued.
- Analysis Last Updated: When the exploitability statement was last updated.
- Additional Details: Any additional information regarding the exploitability statement.
Impact on Vulnerability Filters and Display
Once a vulnerability is annotated with a status of Not Affected or Fixed, it will be removed from both the Total
Vulnerabilities count and the data grid. The filters can always be adjusted to display all vulnerabilities, regardless
of their annotation status.
Policy Gate
There are two parameters available for the vulnerabilities gate and package trigger for Container Image Rule Sets:
missing annotation: If set to True, only show vulnerabilities that are not annotated.annotation status: Comma-separated list of annotation statuses to filter vulnerabilities.
Reports
There are two filter parameters available for reports that include vulnerability contents:
Missing Annotation: If set to True, only include vulnerabilities that are not annotated.Annotation Status: List of vulnerability annotation statuses to filter by.
Generating a VEX Document for a Container Image
The vulnerability annotations can be used to generate a VEX (Vulnerability Exploitability eXchange) document to share the security analysis state with various stakeholders.
A VEX document in the OpenVEX format can be generated for a container image using the API endpoint GET /v2/images/{image_digest}/vex/openvex.