50% of Developers Don’t Scan Their Docker Images for Vulnerabilities at All

50% of Developers Don’t Scan Their Docker Images for Vulnerabilities at All

These are just a few of the key findings from the Docker Security report: Shifting Docker Security Left.

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 risks 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.

Scanning Images During Development

Creating an image from a Dockerfile and even rebuilding an image can introduce new vulnerabilities in your system. Previously, we saw that 68% of users believe that developers have a fair amount of responsibility in container security. Scanning your Docker images during development should be part of your workflow to catch vulnerabilities as early as possible.

When thinking of shifting security left, developers should ideally be able to scan a Dockerfile and their images from their local machine before it is committed to a repository or a build pipeline.

This does not mean that you should replace CI pipeline scans with local scans, but rather that it is preferable to scan at all stages of development, and preferably scans should be automated. Think about automated scans during build, before pushing the image to a registry and pushing an image to a production environment. Refusing that an image go into a registry or enter the production system because the automated scan found new vulnerabilities should be considered a best practice.

Snyk’s recently released container vulnerability management scan Docker images by extracting the image layers and inspecting the package manager manifest info. We then compare every OS package installed in the image against our Docker vulnerability database. In addition to that, it is also crucial to scan the key binaries installed on the images. Snyk also supports scanning the key binaries that are often not installed by the OS package manager (dpkg, RPM and APK), but by other methods such as a RUN command.

When giving developers the tools to scan Dockerfiles and images during development on their local machines, another layer of protection is created and developers can actively contribute to a more secure system in general.

Scanning Containers During Production

It turns out that 91% of respondents do not scan their Docker images in production. Actively checking your container could save you a lot of trouble when a new vulnerability is discovered and your production system might be at risk.

Periodically (for example, daily) scanning your docker image is possible by using the Snyk monitor capabilities for containers. Snyk creates a snapshot of the image’s dependencies for continuous monitoring.

from DZone Cloud Zone

Sharing is caring!

Comments are closed.