Closed paul-ri closed 3 weeks ago
cdupuis
commented
2 months ago The Scout CLI ships with support for VEX. See https://www.docker.com/blog/filter-out-security-vulnerability-false-positives-with-vex/ for how to use this locally. Once you have a VEX JSON file or files, you can pass them into the docker scout cve --vex-location option. Could you give this a try and see if this fits your workflow?
Support VEX/suppression on the platform is currently under development.
paul-ri
commented
2 months ago Oh thanks, I remember skipping this section as I saw it required a Docker account and containerd. So I assumed this was something I couldn't run locally.
Am I right to understand I should be able to use VEX to suppress vulnerabilities reporting of a local image? The workflow I am interested in is: Scan images from a Linux machine of images from an Azure Container Registry (non premium); expecting to be able to scan any local images too.
I have failed to be able to use this suppression when trying both with the tutorial and with a local image.
Support VEX/suppression on the platform is currently under development.
Are my issues kind of expected if things are still in beta-ish, and I should just wait?
/etc/docker/daemon.json:
{
"experimental": true,
"debug": false,
"features": {
"buildkit": true,
"containerd-snapshotter": true
}
}mdupaulri as ORG: https://hub.docker.com/r/mdupaulri/scout-demo-service (the image doesn't appear pushed as of writing, yet it is present on my Docker Scout dashboard)
Output of docker scout cves --only-cve-id CVE-2022-24999 --vex-location . in the collapsed panel``` { "@context": "https://openvex.dev/ns/v0.2.0", "@id": "https://openvex.dev/docs/public/vex-766b244a12d8cea5a4f2a19cdc1c0511710d29ac11ab7a7ccaea09ea3cde3255", "author": "author@example.com", "timestamp": "2024-04-16T19:12:35.965284085+01:00", "version": 1, "statements": [ { "vulnerability": { "name": "CVE-2022-24999" }, "timestamp": "2024-04-16T19:12:35.96528476+01:00", "products": [ { "@id": "pkg:docker/mdupaulri/scout-demo-service@v1", "subcomponents": [ { "@id": "pkg:npm/express@4.17.1" }, { "@id": "pkg:npm/qs@6.7.0" } ] } ], "status": "not_affected", "justification": "vulnerable_code_not_in_execute_path" } ] } ```
``` ## Overview │ Analyzed Image ────────────────────┼─────────────────────────────────────────────── Target │ digest │ ccefb2ffc4eb platform │ linux/amd64 provenance │ https://github.com/docker/scout-demo-service │ https://github.com/docker/scout-demo-service/blob/0de180be8a6e8deb3b63cd52b0811b3a23d91c31 vulnerabilities │ 0C 2H 0M 0L size │ 19 MB packages │ 72 │ Base image │ alpine:3.14 │ be9bdc0ef8e9 ## Packages and Vulnerabilities 0C 1H 0M 0L express 4.17.1 pkg:npm/express@4.17.1 https://github.com/docker/scout-demo-service/blob/0de180be8a6e8deb3b63cd52b0811b3a23d91c31/Dockerfile#L14-L17 RUN apk add --no-cache npm \ && npm i --no-optional \ && npm cache clean --force \ && apk del npm ✗ HIGH CVE-2022-24999 [OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities] https://scout.docker.com/v/CVE-2022-24999?s=gitlab&n=express&t=npm&vr=%3C4.17.3 Affected range : <4.17.3 Fixed version : 4.17.3 CVSS Score : 7.5 CVSS Vector : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H 0C 1H 0M 0L qs 6.7.0 pkg:npm/qs@6.7.0 https://github.com/docker/scout-demo-service/blob/0de180be8a6e8deb3b63cd52b0811b3a23d91c31/Dockerfile#L14-L17 RUN apk add --no-cache npm \ && npm i --no-optional \ && npm cache clean --force \ && apk del npm ✗ HIGH CVE-2022-24999 [Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')] https://scout.docker.com/v/CVE-2022-24999?s=github&n=qs&t=npm&vr=%3E%3D6.7.0%2C%3C6.7.3 Affected range : >=6.7.0 : <6.7.3 Fixed version : 6.7.3 CVSS Score : 7.5 CVSS Vector : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H 2 vulnerabilities found in 2 packages LOW 0 MEDIUM 0 HIGH 2 CRITICAL 0 What's Next? View base image update recommendations → docker scout recommendations mdupaulri/scout-demo-service@sha256:ccefb2ffc4eb4369735bc0af04abe6ace855db552bff99fc6e937ab0037f0225 ```
python base image. Basically ran the following:
docker pull python
vexctl create \
--product "pkg:docker/python" \
--vuln CVE-2018-20225 \
--subcomponents 'pkg:pypi/pip@24.0' \
--status not_affected \
--justification vulnerable_code_not_in_execute_path \
--file CVE-2018-20225.vex.json
docker scout cves --vex-location . --only-cve-id CVE-2018-20225 python## Overview
│ Analyzed Image
────────────────────┼──────────────────────────────
Target │ python:latest
digest │ e0e2713ebf0f
platform │ linux/amd64
vulnerabilities │ 0C 1H 0M 0L
size │ 381 MB
packages │ 573
## Packages and Vulnerabilities
0C 1H 0M 0L pip 24.0
pkg:pypi/pip@24.0
✗ HIGH CVE-2018-20225 [OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities]
https://scout.docker.com/v/CVE-2018-20225?s=gitlab&n=pip&t=pypi&vr=%3E%3D0
Affected range : >=0
Fixed version : not fixed
CVSS Score : 7.8
CVSS Vector : CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
VEX : not affected [vulnerable code not in execute path]
: Unknown Author
1 vulnerability found in 1 package
LOW 0
MEDIUM 0
HIGH 1
CRITICAL 0
What's Next?
View base image update recommendations → docker scout recommendations python:latestIs this an expected workflow?
cdupuis
commented
2 months ago Thanks for the detailed response, @paul-ri.
Am I right to understand I should be able to use VEX to suppress vulnerabilities reporting of a local image? The workflow I am interested in is: Scan images from a Linux machine of images from an Azure Container Registry (non premium); expecting to be able to scan any local images too.
Yes, this is expected to work locally without any paid account or subscription.
Support VEX/suppression on the platform is currently under development. Are my issues kind of expected if things are still in beta-ish, and I should just wait?
No, the VEX support in the CLI should work.
Let's take a look at your two cases:
I think the issue here (which if true is a bug) is that the command doesn't specify an image ref and I can see how this would make the VEX matching fail. To confirm, could you try with docker scout cves --only-cve-id CVE-2022-24999 --vex-location . mdupaulri/scout-demo-service:v1 as command?
This did actually work as indicated by the VEX section in the following output:
✗ HIGH CVE-2018-20225 [OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities]
https://scout.docker.com/v/CVE-2018-20225?s=gitlab&n=pip&t=pypi&vr=%3E%3D0
Affected range : >=0
Fixed version : not fixed
CVSS Score : 7.8
CVSS Vector : CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
VEX : not affected [vulnerable code not in execute path]
: Unknown Author If you want to filter out _notaffected CVEs, supply the --only-vex-affected command line option to the cves command. Using that, those CVEs should be gone from the result.
Let me know if that helps. And again, many thanks for raising those issues here.
paul-ri
commented
2 months ago That's helpful.
This did actually work as indicated
That is so true I am sorry. I ran these commands so many times failing at first as I tried the tool, that I eventually just learned to look at the final summary lines. Adding --only-vex-affected would have helped to see this.
Yet, the fact I missed it might be related to the following odd behaviour:
To confirm, could you try with docker scout cves --only-cve-id CVE-2022-24999 --vex-location . mdupaulri/scout-demo-service:v1 as command?
I do see the VEX line being added to the report when running the command. But only if this if the first command being ran after building. If I run docker scout without the image specified, it fails. And if I run it again with the image name specified, it fails!
Here's a recording. Commands ran are:
docker build --provenance=true --sbom=true --tag mdupaulri/scout-demo-service:v1 --push .
# No CVE found
docker scout cves --only-cve-id CVE-2022-24999 --vex-location . --only-vex-affected mdupaulri/scout-demo-service:v1
# CVEs found for all subsequent commands
docker scout cves --only-cve-id CVE-2022-24999 --vex-location . --only-vex-affected
docker scout cves --only-cve-id CVE-2022-24999 --vex-location . --only-vex-affected mdupaulri/scout-demo-service:v1
docker scout cves --only-cve-id CVE-2022-24999 --vex-location . --only-vex-affected mdupaulri/scout-demo-service:v1
docker scout cves --only-cve-id CVE-2022-24999 --vex-location . --only-vex-affected
docker scout cves --only-cve-id CVE-2022-24999 --vex-location . --only-vex-affected mdupaulri/scout-demo-service:v1https://github.com/docker/scout-cli/assets/54000402/4c198fac-c829-41a2-8b14-aecad2f2a051
If you want me to run anything else, happy to try. I can't event think of what to try here to debug this, I don't see a verbose option.
I will try with my own images again tomorrow
TylerHaigh
commented
2 months ago I've been working with scout and vex files the last few days and I can't quite understand why it works sometimes ...
On two separate builds of a docker image, the scout cli will either recognise the vex file, or it will not.
cdupuis
commented
2 months ago @TylerHaigh, thanks for experimenting with this. The current version of the CLI enforces the product/@id to be the name of the image that you are running the CLI against. Given the VEX statements are successfully applied against tyler/plt-mock-hl7-server I assume that's probably the product/@id using the statements? Is that correct? If so, try adding another product entry for <AZURE_ACR>.azurecr.io/tyler/plt-mock-hl7-server.
This could also be caused by us creating invalid PURLs for non Docker Hub registry images. Could you share your VEX file here?
TylerHaigh
commented
2 months ago Thanks @cdupuis I'll have a look into the product/@id. Does that mean the pkg:npm/semver@5.7.1 package (see below) should be a sub-component?
CVE-2022-25883.vex.json File below
{
"@context": "https://openvex.dev/ns/v0.2.0",
"@id": "https://openvex.dev/docs/public/vex-87eecb66df96f25f6ed58d1a9904dd737dfaa6c8594ff384d95eed60a5b7e7c9",
"author": "tyler.haigh@github.com",
"timestamp": "2024-04-30T16:13:24.1687828+10:00",
"version": 1,
"statements": [
{
"vulnerability": {
"name": "CVE-2022-25883"
},
"timestamp": "2024-04-30T16:13:24.1687828+10:00",
"products": [
{
"@id": "pkg:npm/semver@5.7.1",
}
],
"status": "not_affected",
"justification": "vulnerable_code_not_present"
}
]
}Thanks, this indicates that there's something wrong with us internally using PURLs for images coming from non-Docker Hub registries. I'll see if I can reproduce this.
paul-ri
commented
2 months ago I can't replicate my own commands mentioned in my last message. The vulnerabilities are properly ignored now in every case.
I'm still on docker-scout 1.7.0. So not much has changed except a bunch of reboot and updates of the OS (today's docker version: Docker version 26.1.0, build 9714adc6c7).
So it's confusing. I won't investigate more for now.
TylerHaigh
commented
2 months ago Definitely looks to be related to non-Docker hub registries., I've tried three variations of the vex file. Results below:
cdupuis
commented
2 months ago Thanks for all the feedback. We found an issue and put a fix in. This will be released with the next version of the CLI.
Hi,
It would make sense for some of my use cases to be able to ignore some CVEs. For example a vulnerable library may be present in the image but is unused in the application.
Trivy for example provides a way to ignore CVE by IDs via an ignore file: https://aquasecurity.github.io/trivy/dev/docs/configuration/filtering/#by-finding-ids
Can I suggest:
--ignore-ids/--filter-ids/--filter-ids... ? Although a file is good as I can write comments to justify the reason to ignore them.Currently, I've had to create a wee python script that reads a YAML file where I can add which image should ignore what CVEs; I then read the JSON output of Scout to report on the result.
Thanks for providing Docker Scout!