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.
docker scanoften 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 runFROM 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
FROMlayer. 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 scanwould be improved if the--exclude-baseoption 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.