feat(vex): support non-root components for products in OpenVEX

[knqyf263]

Background

Currently, Trivy uses VEX statements with fixed and not_affected statuses to filter out vulnerabilities.

Current Implementation

In this PR, we added limited support for OpenVEX subcomponents. With this change, VEX can be applied to scans when the product is the root component and the subcomponent is the leaf component, i.e., the component with the vulnerability. For container image scans, if the product ID is the scan subject, the PURL of the image, the VEX is applicable as the image is a root component.

However, it does not work with VEX for non-root components within that container image. In the following example, a VEX document for Application B doesn't work since it is a non-root component.

Enhancement

This PR extends that functionality to allow VEX with non-root components as the product ID to be applied as well. This means that when scanning a container image like ghcr.io/aquasecurity/trivy:0.51.1, the following VEX can be passed:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "author": "Aqua Security",
  "role": "Maintainer",
  "timestamp": "2024-05-20T19:07:16.853479631-06:00",
  "version": 1,
  "statements": [
    {
      "vulnerability": {
        "name": "CVE-2024-21626"
      },
      "products": [
        {
          "@id": "pkg:golang/github.com/aquasecurity/trivy",
          "subcomponents": [
            {
              "@id": "pkg:golang/github.com/opencontainers/runc"
            }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }
  ]
}

With this extension, there is no longer a need to issue VEX for all container images to suppress this vulnerability, and VEX for applications can be reused. In the example above, the same VEX can be applied to all container images, including the pkg:golang/github.com/aquasecurity/trivy binary.

Implementation

Applying VEX to components in the middle of the dependency tree is not straightforward because the vulnerable component may also be used by other components. This means that all possible paths must be explored to ensure that all paths are unaffected.

1. Single path
   If Library C is used only by Library B and Library B has a VEX statement declaring "not affected", we can consider Container Image A is also not affected.

The VEX statement would be as follows:

  "statements": [
    {
      "vulnerability": {
        "name": "CVE-XXXX-YYYY"
      },
      "products": [
        {
          "@id": "pkg:golang/library-b",
          "subcomponents": [
            {
              "@id": "pkg:golang/library-c"
            }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }

2. Multi paths

However, consider a scenario where Application A depends on Library B and Library D, and both Library B and D depend on Library C. In other words, there are multiple paths from Library C to the root component, which is Application A in this example.

In this case, even if there is a VEX statement for Library B declaring that it is not affected by the vulnerability in Library C, we cannot definitively say that Application A is not vulnerable to the vulnerability in Library C. This is because Library D might be using Library C in a vulnerable way. Therefore, we also need to check the VEX for Library D, and if it is "affected" or if no VEX exists (default is considered affected), Application A is still considered affected.

On the other hand, if Library D also has a VEX statement declaring it as not affected, Application A is deemed not affected.

In this PR, Trivy generates as complete a dependency tree as possible, performs a full path exploration, and filters out the vulnerability only when all paths to the root component are unreachable.

Note

CSAF relationship support will be implemented in another PR.

Related issues

• feat(vex): add support for relationships/subcomponents #6077

Related PRs

• feat(vex): consider root component for relationships #6313

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[DmitriyLewen]

LGTM.
Left a couple comments.

[knqyf263]

@DmitriyLewen Done!