80% of developers are not addressing Docker security
William Henry
2019年4月17日
0 分で読めますWelcome to the Docker security report: Shifting Docker security left.This report is split into several posts:
The top two most popular Docker base images each have over 500 vulnerabilities
80% of developers are not addressing Docker security
Or download our lovely handcrafted pdf report, which contains all of this information and more in one place.
Container security ownership
When Docker is an integral part of your own ecosystem, somebody needs to take responsibility for it. Most people agree that responsibility is a shared effort. When asked who owns container security (with the option to select more than one answer) most respondents believed that developers should be responsible for owning container security (68%), thereafter followed by operations (39%).
Although security ownership is a shared effort within DevOps, or better yet—DevSecOps, we see that the majority believe that developers play a key role. This is similar to what we see regarding the security responsibility for application code. According to The State of Open Source Security report, 81% of respondents believe that developers should own the security of their applications.
Organizations may want to also consider partnering with the trusted vendor of the base images in order to manage some of the security risk when working with your CI/CD pipelines. Vendors such as Red Hat provide scanned and signed images. They also provide fast turnaround to CVEs on base images that can then trigger application image rebuilds in CI/CD pipelines. This doesn’t negate the need for scanning during the DevOps lifecycle but reduces the latency between vulnerable production images and healthy production images. Sharing the risk with a third party can help reduce the overall risk.
Security testing the OS layer
Unfortunately, just 19% of developers claim to test their Docker images during development for vulnerabilities in the Operating System layer. This means that over 80% of developers do not shift security left to test their images during development—unfortunately, discovering vulnerabilities later is costlier.
On top of this, half (50%) of the users don’t perform any sort of scan for the OS layer of their Docker image. It’s important to understand what is in the OS layer of your images. Blindly using Docker images is very dangerous as you’ll no doubt bring in countless vulnerabilities. You can easily reduce the risk by scanning them and first understanding the known vulnerabilities in each image you’re considering.
By using a scanning tool for Docker images, such as the one Snyk provides, the vulnerable images can be caught throughout the complete development cycle. Starting locally, when a developer selects a particular Docker image, scanning prevents vulnerable Docker images coming into your environment. Repeat scanning in all stages and through the end of the CI/CD pipeline to prevent an image with known vulnerabilities from going into production.
Vulnerabilities in images are naturally discovered as time passes, making it crucial to keep track of your production images. The median time before a vulnerability is found and reported is 2.5 years. Currently, 9% of users claim to scan their images when in production. An image might have been safe when it was deployed in production, but from that point forward over 90% of developers wouldn’t know the current security status of their images.
Finding out about vulnerabilities
We also asked how people find out that a container they are running contains disclosed vulnerabilities. 45% probably never check. A reasonable amount (15%) of the respondents check public databases such as the CVE database. Keep in mind that the CVE database is only the tip of the iceberg though. The process of registering a CVE may take several weeks and many vulnerabilities might not even become a CVE entry, but may still be a major risk to your system.
Continue reading:
The top two most popular Docker base images each have over 500 vulnerabilities
80% of developers are not addressing Docker security