Over half of publicly available Docker Hub container images contain at least one critical vulnerability, according to a major new study.
Cybersecurity startup Prevasio scanned all four million images hosted at Docker Hub, the world’s most popular repository service for Linux-based containers.
“Each image was executed in an isolated controlled environment,” it explained in a new report. “During the execution, Prevasio has analyzed each container’s behavior, scanned all of its files and also performed a full vulnerability assessment of its packages and software dependencies.”
In total, 51% of those images scanned contained one or more critical vulnerabilities.
Additionally, over 6000 were rated potentially harmful or malicious, although these only accounted for less than 1% of the total. Of these, the largest number (44%) were coin miners, followed by malicious npm packages (23%), hacking tools (20%) and Windows malware (6%).
The news should be concerning for a DevOps community that uses publicly available containers in large numbers to speed up the development cycle.
Earlier this year, a report from Sonatype found that a fifth (21%) of DevOps respondents who admitted suffering a breach related to their application development process said it was because of third-party components.
Earlier this year, Docker announced a partnership with Snyk which will integrate vulnerability scanning into the Docker workflow, although this would still leave the problem of malicious images.
Tim Mackey, principal security strategist at the Synopsys CyRC, argued that when they use third-party images from the Docker Hub, DevOps teams are implicitly stating that they trust the security practices of the author of that container image.
“Such implicit trust is risky from a security perspective, which is why many organizations are now creating hardened container images where the image hardening process is managed by a dedicated team skilled in operating system hardening, which is separate from the core development team,” he added.
“These hardened images are then pushed to an internal registry and policies are defined that only allow images originating from hardened images in that internal registry to execute in a production cluster.”