scout-cli
scout-cli copied to clipboard
docker
Docker scout is misreading base image version number
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.
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
$ 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.
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-alpinefollowing 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.
@aelgasser @mikeparker Docker Scout's recommendation might be based on several factors, such as popularity, stability, or fewer detected vulnerabilities in the recommended base image. However, this might not always align with the need to stay on the latest version for features or security patches. some of steps in my opinion to handle recommendation:- 1.Manual verification 2. Integration with CVE DB:- Integrate with CVE databases or other security tools to cross-verify the vulnerabilities reported by Docker Scout. This provides a comprehensive view and helps in making informed decisions 3. sample script to automate the recommandation:-
#!/bin/bash
# Define the image
IMAGE="test_scout:latest"
# Clear Docker Scout cache
docker scout cache prune --sboms --yes
# Run Docker Scout quickview
QUICKVIEW_OUTPUT=$(docker scout quickview $IMAGE)
echo "$QUICKVIEW_OUTPUT"
# Check for outdated base image recommendations
RECOMMENDATIONS_OUTPUT=$(docker scout recommendations $IMAGE)
echo "$RECOMMENDATIONS_OUTPUT"
# Parse the recommendations to check for older versions
if echo "$RECOMMENDATIONS_OUTPUT" | grep -q "1.20-alpine"; then
echo "Docker Scout recommended an older version (1.20-alpine)."
echo "Recommendation will be ignored as we are using the latest version (1.21-alpine)."
# Document the decision
echo "[$(date)] Docker Scout recommended an older version (1.20-alpine). Ignored the recommendation to use the latest version (1.21-alpine)." >> scout_decisions.log
fi
# Additional steps to handle image security based on custom policies or further checks
# ...
let me know, if the above helps Thanks
