You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be good to add the pkg.Source.Name and pkg.Source.Digest information to the matchable product identifiers when using VEX documents to filter out vulnerabilities. This would allow for VEX document filtering on locally built images, which currently doesn't work when scanning images built locally with docker build. In turn, this would help with CI workflows that use VEX documents to filter out triaged vulnerabilities in locally built images.
I have explained my investigation and reasoning in more detail below. If the change sounds reasonable (it is minor), I am happy to make it myself.
Why is this needed:
When using a VEX document to filter out vulnerabilities in Grype, the product field is used to specify which images in particular a vulnerability annotation applies to.
As shown above, this works as expected (1 ignored vulnerability, where the pkg:oci/nginx matches the pURL of the container being scanned) when downloading an image from a container registry. However, when building an image locally, this doesn't work.
Dockerfile:
FROM nginx:1.27.0
USER app
then run: $ docker build -t nginx-grype-test ., and update the VEX document above to specify the new image name:
However, Grype doesn't ignore the same vulnerability in this new image, despite there being essentially no difference in the images:
$ grype nginx-grype-test --vex vex.json| grep CVE-2023-31484
✔ Vulnerability DB [no update available]
✔ Loaded image nginx-grype-test:latest
...
└── by status: 0 fixed, 158 not-fixed, 0 ignored
perl-base 5.36.0-7+deb12u1 (won't fix) deb CVE-2023-31484 High
Doing some digging + adding some extra debug logging, I've discovered that the generation of product identifiers to match on happens here, and that in the case of locally built images, v.RepoDigests doesn't contain any information, so there's practically no way for Grype to successfully product match on a locally built image. This breaks CI workflows, for example building and then scanning a container with VEX documents applied.
However, the pkgContext.Source.Name and pkgContext.Source.ID (the local image name and digest) are all set, so it would be trivial (and sensible) to add them to the list of matchable fields for VEX documents, which would fix the issue. productIdentifiersFromContext already has a TODO that suggests We could generate more identifiers to match better., and I think this change would help with that.
As mentioned earlier, I have a good idea of what needs to be done, so if this seems like a sensible approach I'll go ahead and implement it.
cc @puerco as the original author of the VEX functionality.
The text was updated successfully, but these errors were encountered:
Hi @ferozsalam, we think this makes sense, it would be great if you wanted to implement it and send in a PR. Let us know if you have any trouble or any questions, and thanks in advance!
What would you like to be added:
It would be good to add the
pkg.Source.Name
andpkg.Source.Digest
information to the matchable product identifiers when using VEX documents to filter out vulnerabilities. This would allow for VEX document filtering on locally built images, which currently doesn't work when scanning images built locally withdocker build
. In turn, this would help with CI workflows that use VEX documents to filter out triaged vulnerabilities in locally built images.I have explained my investigation and reasoning in more detail below. If the change sounds reasonable (it is minor), I am happy to make it myself.
Why is this needed:
When using a VEX document to filter out vulnerabilities in Grype, the
product
field is used to specify which images in particular a vulnerability annotation applies to.So for example the following VEX document:
can be used against
nginx:1.27.0
(make sure you are ignoring fixed VEX statuses in yourgrype.yaml
:As shown above, this works as expected (1 ignored vulnerability, where the
pkg:oci/nginx
matches the pURL of the container being scanned) when downloading an image from a container registry. However, when building an image locally, this doesn't work.Dockerfile:
then run:
$ docker build -t nginx-grype-test .
, and update the VEX document above to specify the new image name:However, Grype doesn't ignore the same vulnerability in this new image, despite there being essentially no difference in the images:
Doing some digging + adding some extra debug logging, I've discovered that the generation of product identifiers to match on happens here, and that in the case of locally built images,
v.RepoDigests
doesn't contain any information, so there's practically no way for Grype to successfully product match on a locally built image. This breaks CI workflows, for example building and then scanning a container with VEX documents applied.However, the
pkgContext.Source.Name
andpkgContext.Source.ID
(the local image name and digest) are all set, so it would be trivial (and sensible) to add them to the list of matchable fields for VEX documents, which would fix the issue.productIdentifiersFromContext
already has a TODO that suggestsWe could generate more identifiers to match better.
, and I think this change would help with that.As mentioned earlier, I have a good idea of what needs to be done, so if this seems like a sensible approach I'll go ahead and implement it.
cc @puerco as the original author of the VEX functionality.
The text was updated successfully, but these errors were encountered: