Allow specification of SBOM product purl during scan

[lucastheisen]

Description

When scanning an image from a repo, the purl of the product is correct, but if you pull the image first then scan from local build or oci artifact, the product purl is not the same. Because it is not the same, i cannot use that product purl to limit the scope of vex based suppressions.

For example:

ltheisen@PC ~/egit/docker-library-hello-world
$ trivy image docker.io/hello-world:latest --format cyclonedx | grep ref
2025-08-25T16:40:15-04:00       INFO    "--format cyclonedx" disables security scanning. Specify "--scanners vuln" explicitly if you want to include vulnerabilities in the "cyclonedx" report.
2025-08-25T16:40:15-04:00       INFO    Number of language-specific files       num=0
      "bom-ref": "pkg:oci/hello-world@sha256%3Aa0dfb02aac212703bfcb339d77d47ec32c8706ff250850ecc0e19c8737b18567?arch=amd64&repository_url=index.docker.io%2Flibrary%2Fhello-world",
      "ref": "pkg:oci/hello-world@sha256%3Aa0dfb02aac212703bfcb339d77d47ec32c8706ff250850ecc0e19c8737b18567?arch=amd64&repository_url=index.docker.io%2Flibrary%2Fhello-world",

ltheisen@PC ~/egit/docker-library-hello-world
$ docker build amd64/hello-world --tag docker.io/hello-world:latest
[+] Building 0.5s (5/5) FINISHED                                                                                                                                                                                                                                                         docker:default
 => [internal] load build definition from Dockerfile                                                                                                                                                                                                                                               0.1s
 => => transferring dockerfile: 78B                                                                                                                                                                                                                                                                0.0s
 => [internal] load .dockerignore                                                                                                                                                                                                                                                                  0.1s
 => => transferring context: 2B                                                                                                                                                                                                                                                                    0.0s
 => [internal] load build context                                                                                                                                                                                                                                                                  0.1s
 => => transferring context: 10.11kB                                                                                                                                                                                                                                                               0.0s
 => [1/1] COPY hello /                                                                                                                                                                                                                                                                             0.1s
 => exporting to image                                                                                                                                                                                                                                                                             0.1s
 => => exporting layers                                                                                                                                                                                                                                                                            0.1s
 => => writing image sha256:2d6887f5128c5d5fe34e7491b31b92e74c4ed3d0dc0bb8d1fca2a2208fd637b0                                                                                                                                                                                                       0.0s
 => => naming to docker.io/library/hello-world:latest                                                                                                                                                                                                                                              0.0s

ltheisen@PC ~/egit/docker-library-hello-world
$ trivy image docker.io/hello-world:latest --format cyclonedx | grep ref
2025-08-25T16:42:18-04:00       INFO    "--format cyclonedx" disables security scanning. Specify "--scanners vuln" explicitly if you want to include vulnerabilities in the "cyclonedx" report.
2025-08-25T16:42:18-04:00       INFO    Number of language-specific files       num=0
      "bom-ref": "e6be3df4-f3de-4cd1-b2cb-6e7e4a411305",
      "ref": "e6be3df4-f3de-4cd1-b2cb-6e7e4a411305",

According to the vex documentation I have read, you should scope your vex entries by the product you are scanning. In this case it would be something like:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://openvex.dev/docs/public/vex-8b795986b87d39e5b6b6ddbd5e9ff049548c6f83065343b3bcd6024b19933404",
  "author": "A U Thor",
  "timestamp": "2025-08-20T12:22:10.235400227-04:00",
  "last_updated": "2025-08-22T11:29:56.020110317-04:00",
  "version": 9,
  "statements": [
    {
      "vulnerability": {
        "name": "CVE-2025-47907"
      },
      "timestamp": "2025-08-22T11:29:56.020112317-04:00",
      "products": [
        {
          "@id": "pkg:oci/hello-world?repository_url=index.docker.io%2Flibrary%2Fhello-world"
          "subcomponents": [
            {
              "@id": "..."
            }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "this is an example"
    }
  ]
}

The first scan that uses the repo url would properly find the subcomponent, but the second scan would not because it thinks its ref/bom-ref are the uuid of the build and not the actual name it would be pushed to. In theory the image could get pushed then the scan run on the place it is pushed to, but that requires unnecessary network traffic and would mean the image is put in place prior to being scanned (which would be a security risk).

If there was a way to simply state --product-id "pkg:oci/hello-world?repository_url=index.docker.io%2Flibrary%2Fhello-world" as an option to the trivy command it would resolve this issue.

Target

None

Scanner

Vulnerability

[knqyf263]

Instead of adding --product-id, I suggested generating PURL for local images. Please let me know if it doesn't help you.
#9399