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
{{ message }}
This repository has been archived by the owner on Jan 27, 2023. It is now read-only.
Version of Anchore Engine and Anchore CLI if applicable: anchore/grype:latest (Docker image)
What happened:
On our build sever we have multiple tags of each image, not all of which are pushed to the Docker Hub (which for some time have been admitting only new tags for unique, i.e. somehow altered images - and their tags admission logic is pretty much inscrutable, or simply buggy). For instance, the latest locally tag, 20220402, of an image is only present in my local server's docker cache, because the image has not changed (according to Docker Hub's logic) since 20220330 (and this tag is the latest remotely), and to my surprise anchore/grype does not let me scan that latest locally image (only latest remotely is allowed for scanning).
I can imagine what happens when people check generic latest tags... which may refer to two different images - and the latest one available remotely can easily be much older and thus less secure (which can explain some of the false positives which people have reported here, with vulnerabilities patched only locally, but not remotely, because the push to the remote registry is not permitted due to this very scan failing (for... a remote image - a truly "catch 22" situation).
What did you expect to happen:
To check a local image for vulnerabilities. This is the main reason of using CVE scanners - to avoid pushing to production (i.e. to a docker registry) an image that fails a security scan.
How to reproduce
You need to have some local image tag not yet available in the remote repo and scan it with grype.
In my case:
$ docker images | grep ml-fs-py38-lite | grep 20220402
mirekphd/ml-fs-py38-lite 20220402 0e51ec74c30e 3 days ago 1.24GB
$ docker run -it --rm --ngrype anchore/grype --fail-on critical mirekphd/ml-fs-py38-lite:20220402
⠋ Vulnerability DB [importing]
1 error occurred:
* failed to catalog: could not fetch image "mirekphd/ml-fs-py38-lite:20220402": unable to use OciRegistry source: failed to get image descriptor from registry: GET https://index.docker.io/v2/mirekphd/ml-fs-py38-lite/manifests/20220402: MANIFEST_UNKNOWN: manifest unknown; unknown tag=20220402
Other issues
Updating the DB before checking for the image existence seems to me also rather inefficient.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
BUG REPORT
Version of Anchore Engine and Anchore CLI if applicable:
anchore/grype:latest
(Docker image)What happened:
On our build sever we have multiple tags of each image, not all of which are pushed to the Docker Hub (which for some time have been admitting only new tags for unique, i.e. somehow altered images - and their tags admission logic is pretty much inscrutable, or simply buggy). For instance, the latest locally tag, 20220402, of an image is only present in my local server's docker cache, because the image has not changed (according to Docker Hub's logic) since 20220330 (and this tag is the latest remotely), and to my surprise
anchore/grype
does not let me scan that latest locally image (only latest remotely is allowed for scanning).I can imagine what happens when people check generic
latest
tags... which may refer to two different images - and the latest one available remotely can easily be much older and thus less secure (which can explain some of the false positives which people have reported here, with vulnerabilities patched only locally, but not remotely, because the push to the remote registry is not permitted due to this very scan failing (for... a remote image - a truly "catch 22" situation).What did you expect to happen:
To check a local image for vulnerabilities. This is the main reason of using CVE scanners - to avoid pushing to production (i.e. to a docker registry) an image that fails a security scan.
How to reproduce
You need to have some local image tag not yet available in the remote repo and scan it with
grype
.In my case:
Other issues
Updating the DB before checking for the image existence seems to me also rather inefficient.
The text was updated successfully, but these errors were encountered: