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
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
FROM golang:1.21-alpine
WORKDIR /app
RUN echo foo > bar.txt
ENTRYPOINT [ "sh", "cat", "/app/bar.txt" ]
As of today (2024-01-09) 1.21-alpine is the latest tag, this is important.
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
$ docker scout cache prune --sboms
? Are you sure you want to delete all temporary data and all cached SBOMs? Yes
✓ Temporary data deleted
✓ Cached SBOMs deleted
Then docker scout quickview test_scout:latest gives:
$ docker scout quickview test_scout:latest
✓ Image stored for indexing
✓ Indexed 41 packages
Target │ test_scout:latest │ 0C 0H 0M 0L
digest │ ae018a575642 │
Base image │ golang:1-alpine │ 0C 0H 0M 0L
Updated base image │ golang:1.20-alpine │ 0C 0H 0M 0L
│ │
What's Next? View base image update recommendations → docker scout recommendations test_scout:latest Include policy results in your quickview by supplying an organization → docker scout quickview test_scout:latest --org <organization>
And docker scout recommendations test_scout:latest gives:
$ docker scout recommendations test_scout:latest
✓ SBOM of image already cached, 41 packages indexed
Target │ test_scout:latest
digest │ ae018a575642
## Recommended fixes
Base image is golang:1-alpine
Name │ 1-alpine
Digest │ sha256:c56d095992c4857b6cf532808dc847d50d24fe0fc7be1cdc0beacc7ad3da9f1b
Vulnerabilities │ 0C 0H 0M 0L
Pushed │ 2 weeks ago
Size │ 68 MB
Packages │ 41
Flavor │ alpine
OS │ 3.19
│ 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.
Refresh base image
Rebuild the image using a newer base image version. Updating this may result in breaking changes.
✓ This image version is up to date.
Change base image
The list displays new recommended tags in descending order, where the top results are rated as most suitable.
Tag │ Details │ Pushed │ Vulnerabilities
───────────────────────────────┼──────────────────────────────────────────────────────────────────────┼─────────────┼──────────────────────────────
1.20-alpine │ Benefits: │ 1 month ago │ 0C 0H 0M 0L
Minor runtime version update │ • Same OS detected │ │
Also known as: │ • Minor runtime version update │ │
• 1.20.12-alpine │ • Image has same number of vulnerabilities │ │
• 1.20.12-alpine3.19 │ • Image contains similar number of packages │ │
• 1.20-alpine3.19 │ • 1.20-alpine is the third most popular tag with 11K pulls per month │ │
│ │ │
│ Image details: │ │
│ • Size: 100 MB │ │
│ • Flavor: alpine │ │
│ • OS: 3.19 │ │
│ • Runtime: 1.20.12 │ │
│ │ │
│ │ │
│ │ │
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.
The text was updated successfully, but these errors were encountered:
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:
What we advise is the best practice to build your images with full provenance attestations which allows Scout to be much more accurate and enables all kinds of additional functionality down the line such as linking back to exact commits. You can read more about adding provenance attestations here https://docs.docker.com/build/attestations/slsa-provenance/
You can also give the Scout CLI exact details of the base image by using --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:
docker build --pull --force-rm -t test_scout:latest .
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.
The text was updated successfully, but these errors were encountered: