Snyk Container in 2021: Shifting container security all the way left

No matter how you slice it, the use of containers and Kubernetes continues to swell. And recent high profile vulnerabilities-that-shall-not-be-named have shown us how important container security is for an overall application security program. Protecting your own code, your dependencies, and the containerized services you use are all a must.

And the signs of continued rapid adoption of containers are all around us. In 2021, Snyk customers ran over 130 million container tests — 10x more container tests than in 2020! Datadog and Sysdig each report monitoring well over 1 billion containers, and Gartner predicts more than 75% of global organizations will be running containerized applications in production in 2022, up from less than 30% just last year.

As we approach the end of 2021, we’re taking a look back at the big new capabilities in each of Snyk’s products, and in this post we’re going to focus on Snyk Container.

Snyk Container usage skyrockets in 2021

As noted above, Snyk Container was used in over 130 million container tests in 2021 so far. But testing a container is not the ultimate goal of Snyk Container — FIXING container issues is the desired outcome, and here’s what we saw with Snyk Container:

• 56 million vulnerabilities were fixed by Snyk Container users in 2021.

• That comes from running over 133 million container scans on over 2 million images, and detecting over 111 million unique container vulnerabilities. 

  * Note that the number of vulnerabilities is lower than the number of tests because a recurring test on the same image only counts a detected vulnerability once.

And it’s not just scanning images in pipelines and registries. 47,000 Kubernetes projects and 352,000 Git repos with Dockerfiles were also monitored with Snyk Container.

Developer-focused enhancements in Snyk Container

In 2021, Snyk Container added several features to fit into developers’ workflows. Our goal is to make the process of finding and fixing container issues as simple and obvious as we can — so simple that it’s hard not to fix them.

One of the most significant new features was the ability to scan Dockerfiles from source code repositories and to open pull requests to fix issues that are detected. This is a first for a container security product, and the selection of a good, secure base image for an application is a relatively low effort way to reduce as many as 90% of vulnerabilities from a container.

Snyk Container scanning a Dockerfile to provide base image recommendations and fix PRs.

Because the selection of a parent image to build upon is so important, we wanted to ensure that as many users as possible would receive Snyk’s base image guidance, regardless of where in the container lifecycle one chooses to scan. To that end, we changed how we detect the parent image in a container, and as we enter December, well over 80% of all containers tested are now receiving base image guidance, up from ~25% in January.

Percentage of container projects with automatic parent image upgrade advice.

Interestingly, Snyk Container’s base image logic is built around Docker’s official images, so these high parent image guidance rates are a clear indicator of Docker’s continued popularity and importance in the container world.

We also demonstrated our work-in-progress on IDE support for Snyk Container at SnykCon, and along with our continued Docker partnership, this is a great signal of things to come as we continue shifting container security further to the left.

Container workflow and ecosystem improvements

In 2021, we also set out to tackle some nagging issues in container-based workflows that can make fixing issues more complicated. We also wanted to broaden our support for popular container tools in the ever-growing ecosystem.

One of the odd workflow struggles with containers is keeping the Dockerfile and the resulting images linked to one another. Container images don’t have any inherent way of keeping track of the Dockerfile that was used to create them, which can make it challenging to track down who’s responsible for a particular container and which Dockerfile needs to be edited if you want to fix issues. To make this easier in Snyk Container, we decided to follow the OCI standard container labels, which provide a way to connect these two artifacts. In Snyk Container, if you use of these OCI labels, we can automatically show you which container images that you tested with Snyk were built from a particular Dockerfile, making it easy to not only associate container tests with one another, but also get straight to the Dockerfile where you can make a change.

Speaking of embracing standards, we also added the ability to use open policy standards to determine what Snyk monitors in your Kubernetes clusters. Open Policy Agent (OPA) is a popular policy-based control plane for cloud native environments and we’re using it with our Kubernetes monitor to enable you to determine which workloads to automatically monitor, and if and when to delete those workloads if they stop running in your clusters.

We also added new integrations with more popular container ecosystem tools:

• Snyk Container now supports all the most popular container registries, both on-premise and in the cloud, with Harbor, Quay, Nexus, Google Artifact Registry, GitHub, GitLab and DigitalOcean all being introduced this past year.

• Our OpenShift Operator was certified by Red Hat.

• And we made it simpler to setup AWS Elastic Kubernetes monitoring setup with a CloudFormation Registry extension.

Reducing container noise and expanding security details

At first blush, it may seem like an oxymoron to both add more security information AND reduce the noise of container vulnerabilities. But we managed to pull it off in 2021 with Snyk Container.

To reduce the noise of security alerts from containers, and prioritize focus on the most important vulnerabilities to fix, we added social trends data to our vulnerabilities. An increase in chatter on social media is a signal that something malicious might be happening around a vulnerability, which can be a huge helpwith prioritization.

We also improved our security policy capabilities in the Snyk platform, providing new ways to provide more or less focus on vulnerabilities at scale across an organization. For instance, you might want to raise the priority of memory-related vulnerabilities for apps running in your production environment. With Snyk’s security policy interface, you can set a policy like:

• Any apps with the Production attribute or tag…

• and with vulnerabilities that take advantage of either CWE 125 (out-of-bounds read) or CWE 787 (out-of-bounds write)...

• get raised to Critical severity

Snyk security policy to raise criticality of critical, front-end projects with memory-related weaknesses.

And on the side of adding more container security information, we added support for the newest releases of Alpine, Debian, Ubuntu, the new CentOS Stream, and other popular Linux distributions used in containers, as quickly as their maintainers released them. We also changed the way we report on vulnerabilities for Red Hat Enterprise Linux, Amazon Linux, CentOS Stream, which provides more granular details on each CVE, plus additional distribution-specific details around severities.

What to expect from Snyk Container in 2022

As Daniel noted in our Snyk Open Source 2021 in review blog, the secure supply chain is a topic of rising importance and visibility and containers are a major part of the story. Knowing all the components included in your own containers — following your own unique build processes — is becoming more critical. But also knowing what’s included in all the third party, container-packaged apps you might use as well. Your database containers, logging tools, search tools, load balancers and gateways, and more are likely deployed right alongside applications and provide critical functionality. But they can also harbor dangerous vulnerabilities and you need to know about that and be able to roll out new versions as soon as their maintainers provide them.

And there’s far more we want to do to prioritize vulnerabilities, too. That includes both new signals that a particular package or vulnerability is more dangerous, as well as more intelligence and scalable policies that enable developers to tune out the noisy vulnerabilities that really aren’t all that relevant. Combining the two, we’re optimistic we can help Snyk Container users go from hundreds of vulnerabilities detected in a scan, to just a small number of steps to fix the most urgent vulnerabilities, and take the manual burden of vulnerability management off the backs of the overworked security team.

Here’s to a happy and secure 2022!