Feature request: Option for scan to ignore unpatchable vulnerabilities

[mcandre]

docker scan often reports vulnerabilities which are not so actionable. For example, the latest stable Debian release contains known CVE's. Now, a paranoid purist could in theory replace their base OS image layer to another Linux distribution, or even rewrite their application as a fully static binary that can run FROM scratch. But that is not always an option. So certain vulnerability configurations practically will be suffered through / mitigated until the upstream maintainers release patches.

A few related workarounds exist for this, of varying utility. They do not directly address my problem.

One option is to disable scanning the base image layer, which hides the vulnerabilities. But I do want to be told about the vulnerabilities; I just don't want them to always influence the exit code. Maybe I don't have time to entirely rebase my project onto a different FROM layer. But I always want to see these warnings, in any case.

Furthermore, this first option requires the user to have direct access to the original Dockerfile, which may not be available. For example, the images could be built by a third party and imported into your Kubernetes cluster. Or, as has happened at some past engineering roles, sometimes the original source code is simply lost. Now, I don't agree with the practice of generating Docker images from non-Dockerfile sources, such as Spring Boot magic. But the point is that in many contexts, for better or worse, there may not be a Dockerfile available. As an aside, docker scan would be improved if the --exclude-base option did not place a hard requirement for -f.

Another option is to restrict the severity of vulnerabilities influencing the final report and exit code. Some projects may care only about the most extreme vulnerabilities and skip over the others. But that is not the heuristic I want to apply in my projects. I do want to see all identified vulnerabilities. I just want to reduce the exit code to the presence / non-presence of actionable vulnerabilities.

Yet another option is to explicitly ignore the exit code, which is not a good idea in terms of preventing vulnerable software from building in CI/CD pipelines. Some CI/CD pipelines may even ignore ALL exit codes, which risks corruption and data loss. Not what we want. The exit code semantics are important, and could benefit from a higher amount of customization.

For these reasons, I would like to see a command line flag that users can supply to docker scan, which shows vulnerabilities in the base image, but does not present a non-zero exit code. This way maximizes practical value for Docker image maintainers, without placing extra burdens on CI/CD pipeline coding.

[thaJeztah]

Thanks for your feedback. Looks like this is related to the docker scan CLI, which is maintained in a separate repository; let me move this ticket there.

I think some of these suggestions will require changes to Snyk's scanner. "actionable" vs "non-actionable" may be difficult to address (as there's many situations), but perhaps it's possible to have (e.g.) custom allow-lists / ignore-lists for CVE's that you/your team has verified are ok to ignore.

As to the --exclude-base requiring a Dockerfile; I'm not too familiar with the internals of the scanner, but I think this may (unfortunately) be needed, because just from the image information itself, it's not possible to determine which layers are part of the base image, and which layers are part of what you built from that. possibly the name of a base-image could be passed instead (but not sure how that would work if the passed name would have been updated / different digest than the one that was used to build the image).

/cc @silvin-lubecki @glours