Open aelgasser opened 5 months ago
Thanks for the feedback, we probably need to make it more clear what's happening here and would welcome feedback about how to clarify this further.
If you don't build your image with full provenance attestations, Docker Scout cannot know for certain which base image tag you used, and instead makes a best guess on your base image based on the digest, which might be wrong.
There are 2 ways around this:
--tag 1.21-alpine
following the note here:
The base image is also available under the supported tag(s) 1-alpine3.19 , 1.21-alpine , 1.21-alpine3.19 , 1.21.5-alpine , 1.21.5-alpine3.19 , alpine , alpine3.19 │ If you want to display recommendations specifically for a different tag, please re-run the command using the --tag flag.
I just started looking into docker scout and ran it over one of my Golang based images and found an issue that could be blocking if run in a CI/CD pipeline.
it can be reproduced with this dockerfile
As of today (2024-01-09) 1.21-alpine is the latest tag, this is important.
Then use the following command to build an image:
And finally run docker scout to check for any vulnerability with its various options: First, out of precaution, clear docker scout's cache with
docker scout cache prune --sboms
Then
docker scout quickview test_scout:latest
gives:And
docker scout recommendations test_scout:latest
gives:From what I read here (or maybe I misinterpreting the result), docker scout seems to suggest I should 'change' my base image to 1.20-alpine which is older than the 1.21-alpine I use. To me this could create false positives in CI/CD contexts and exceptions to document when we are dealing with customers requesting image audits.