Proposal: Support OCI image as the primary vulnerable software entity (Image-as-a-Product)

[willmurphyscode]

Background

Currently, Grype (and Syft) operate primarily on a "bucket of packages" paradigm. When scanning a container image, the engine looks inside the image for discrete components (RPMs, NPMs, JARs) to match against vulnerability databases.

However, many modern software products (e.g. Grafana, GitLab, and various Red Hat appliances) are distributed and versioned as OCI images. Vulnerabilities (CVEs) for these products are frequently issued against the top-level product version (the image tag or digest) rather than the underlying OS or application dependencies.

Because Grype currently focuses on image contents and does not consider the image itself as a candidate for matching, it suffers from false negatives for these image-as-product CVEs.

Proposal

Introduce a mechanism in Grype where the scan target itself, if it is an image, is a candidate for matching against the vulnerability database. This enhancement requires a few capabilities:

1. Grype needs to recognize the image, e.g. "this image is gitlab-ce" is an image-as-product image
2. Vunnel and Grype-DB need to pull in this data. (Red Hat CSAF already has some pkg:oci/... PURLs in vex/advisory data
3. Grype needs a way to match against this data.

The next step here is to research what fields are available to Grype today to identify the image, and research which vendors of image-as-product products have security feeds and what sort of data is in those feeds to line things up.

[kzantow]

Regarding 3: one approach which would move towards the package-based structures many SBOMs express: create a package from the source, include reference from contained packages -- either a direct "container" property or "contained-by" relationships to the appropriate packages like this PR, and add a container matcher that could be used to surface this information and include/exclude vuln results for related packages. This would also support nested sources, if we end up adding support later. Just one suggestion based on the current state of things.