You can read more on the background within the following Medium post: Testing docker CVE scanners. Part 2.5 — Exploiting CVE scanners
Most Docker image scanners make use of shell access, run package managers, if you run it on the Dockerfile you don't know you could expect. Running them on untrusted code can lead to command execution, some of the scanner providers don't consider this an issue, they (probably rightly) expect people to expect this. However, keep this in mind whenever you use these tools, especially if you add it to your CI/CD pipeline or other security automation where this might become an issue, most likely to escalate privilege or attack your CI or security automation itself.
All issues have been fixed by the vendors or considered as not a security issue
- Anchore runs as a service, attacking it is more interesting because it might have its own rights or could be a way to gain persistance. They do not run package managers but there are shell shananigans non the less. This leads us to CVE-2020-11075, which is specific to them but shows how scanning docker images is hard to defend.
- For scanners, such as FOSSA, Snyk or WhiteSource, that run package managers directly to resolve dependencies, you can obviously run commands through gradlew or Podfiles
- The example for Snyk shows how running docker commands to examine the images can result in code execution. But in general shelling out often is usually a bad idea for security.
- Similarly exploits on WhiteSource show how you can execute commands either by tricky directory names or again by manipulating (through injection) values that will be arguments for shell commands.