Docker containers are great in that it’s easy to get started building an application using frameworks and components that others have made available via open source projects. The challenge, however, is not all those projects are current in terms of their cybersecurity patches. In fact, a developer of a framework may not even be actively supporting it anymore.
A new report from vulnerability management platform vendor Kenna Security highlights the extent of the problem in the Docker community. Via the VulnerabilitiesContainer.org site, Kenna Security is sharing the results of analyses of containers being reused widely that find some of these open source projects have hundreds of unresolved Common Vulnerabilities and Exposure (CVE) issues.
Jerry Gamblin, principal security engineer for Kenna Security, says more than 20% of the files contained at least one vulnerability that would be considered high-risk. More than 60% of the top Docker files held a vulnerability that had a Kenna Risk Score above 330. Leveraging the open source Trivy container scanning tool to identify container vulnerabilities, Kenna developed the Kenna Risk Score model that rates risk from 0 to 1,000. Scores below 330 can be considered low-risk; scores between 330 and 660 are considered medium-risk; and scores above 660 are considered high-risk.
Overall, the Kenna Security report finds:
- Average CVE’s per container: 176
- Median CVE’s per container: 37
- Average Kenna Risk Score: 400
- Average last update day: 10/23/2018
- Median last update day: 4/17/2019
The containers analyzed by Kenna Security have been pulled more than 20.9 billion times, so the potential for container exploits is significant. The average container has been pulled 21 million times, with the median being a little more than 4 million pulls.
The oldest container on the list, abh1nav/cassandra, had more than 1.5 million pulls. It was last updated in May 2015 and has more than 431 open container vulnerabilities, giving it a Kenna risk score of 720. Keyvanfatehi/sinopia has the distinction of having the most open CVEs, with 2,004, and has been pulled 1.7 million times.
Given these high risks, Gamblin says organizations would be a lot more secure if they build their own containers rather than reusing ones in the wild. There’s always the risk that the software loaded into a container will have a known vulnerability. However, organizations that scan containers before deploying them in a production environment are much more likely to discover those vulnerabilities. When organizations pull an existing container, they would be well-advised to make sure that whoever created it is actively using the container in a production environment that is part of their regular job, not a hobby they can walk away from at any time, he says.
Of course, outdated code from open source projects that are not being maintained is not a new problem. The open source landscape is riddled with such projects. However, with the rise of containers, the number of projects from which developers may pull a container has exacerbated the issue.