feat(vex): add support for relationships/subcomponents

[knqyf263]

Description

Trivy currently doesn't consider relationships in VEX. It simply supports a list of products.

   "relationships": [
      {
        "product_reference": "runc-v1.1.12",
        "category": "default_component_of",
        "relates_to_product_reference": "trivy-0.49.0",
        "full_product_name": {
          "product_id": "trivy-0.49.0-runc",
          "name": "Trivy uses runc library"
        }
      }
    ]
  }

In the above example, Trivy should apply VEX to runc only used in Trivy.

[ferozsalam]

👋 hey @knqyf263 - I just came across similar behaviour yesterday when looking at using Trivy to scan some images along with a VEX file.

I'm having a related issue - suppose I had a VEX statement like the following to represent an attestation made about the bash package in blah container:

    {
      "vulnerability": {
        "name": "CVE-2022-3715"
      },
      "products": [
        {
          "@id": "pkg:oci/blah",
          "subcomponents": [
            {
              "@id": "pkg:deb/ubuntu/[email protected]"
            }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    },

In Trivy, this doesn't work to match when scanning the blah container with the --vex flag - the product ID needs to be pkg:deb/ubuntu/[email protected] in order to make it work. But this means that there's no way of representing which container (which in my case is the product itself) is affected.

In Grype, the above statement would correctly match when scanning the blah container, and excludes only the result affecting the bash deb if the CVE affects multiple packages within the container.

To me, Grype's behaviour is more intuitive. I'd be keen to see Trivy and Grype support a consistent interpretation of VEX documents as well, to avoid having to publish multiple VEX documents, one for each scanner.

I'd be interested to know your thoughts on this, and happy to help contributing to any changes that are required. Should this be a separate issue, or does it fit in with the changes that you are proposing here?

[knqyf263]

Yes, it's in the scope of this issue, but it's broader support than the relationship between container image and packages. We'll correctly build the dependency graph and apply VEX to the graph.

[knqyf263]

@ferozsalam This task is yet incomplete, but your case is already supported in v0.50.0.

[ferozsalam]

@knqyf263 awesome, thank you!