Defining developer-first container security

Have you shifted left, yet? That’s the big trend, isn’t it? It’s meant to signal a movement of security responsibilities, moving from central IT teams over to developers, but that’s trickier than it sounds. Simply taking tools that are intended for use by security experts and making them run earlier in the supply chain does not provide developers with meaningful information. It’s that part about enabling organizations to shift the responsibility that we work hard to enable here at Snyk. And that’s part of why we're excited about today’s announcement of our ability to automate fix PRs for containers, following on to our recent announcement of elevating Dockerfiles to first-class status in your git repos.

Helping developers build better, more secure containers has been our North Star for Snyk Container since we first released it back in 2019 and we’re proud to say we have helped Snyk customers and users eradicate 5.8 million vulnerabilities from their containers to date, and the pace is picking up since we added the new Dockerfile and fix pull request features.

Why runtime container security isn’t used by developers

What we’ve found as we talk to customers and Snyk Container users about this domain is that most have good ideas for what they “should” do when it comes to building secure containers: the security teams have policies in place and there are plenty of “Top 10 container best practices” lists all over the internet for developers and they’re incredibly popular. (Our own container top 10 list is one of our most popular blog posts of all time!) But when it comes to putting those policies into practice, only 45% of global security decision makers report that they have enough tooling in place to support those policies, according to Forrester’s Best Practices for Container Security report. So, then, it’s perhaps no surprise to learn that organizations do not enforce best practices like using lightweight images.

This points to a problem with the idea of simply “shifting left” with existing tools. Docker’s coming up on their 8th birthday and container runtime security tools have been around for about 5 of those years. And still, the top four challenges given for the lack of enforcement with existing security tools, according to an ESG study, are:

• Developers are not utilizing tools we’ve invested in effectively

• Developers lack the knowledge to mitigate issues identified

• Adds friction and slows down our development cycles

• Difficulty or lack of integration between different application security vendor tools

This is not meant as a knock on runtime security - it’s absolutely necessary. For security of almost every application most companies have invested in both code security tools and operational security tools, each with a different user in mind. Containers are fun because they combine aspects of both into one convenient package, and yet, both users still exist.

How Snyk enables you to truly “shift left” to secure containers

Snyk Container is the only solution built from the ground up to make security part of a developers’ everyday thinking and build processes. We saw an issue with merely presenting a long list of vulnerabilities that was typical in security-minded tools. Instead, Snyk Container has been providing direct guidance to developers to fix container issues, starting with our base image recommendations:

The guidance steers developers to up-to-date and slimmer base images, reducing the vulnerability “surface area”. Now with Dockerfile scanning and fix PRs we take this a step further to automate these recommendations. Best of all, Snyk Container is agnostic when it comes to how you choose to run your containers. There are no sidecars, no agents, and no special privileged pods to run in Kubernetes to get Snyk Container to work.

Scaling security as container usage grows

Of course Snyk Container works where developers work. Snyk Container can be used by developers directly on their desktop using our CLI. Additionally, it's available through integrations with your choice of source code managers (including GitHub code scanning), any CI/CD tool, container registries, as well as integrating with Kubernetes to scan workloads as they’re deployed or updated in your clusters.

And as the number of containerized workloads grows, it becomes even more important to help developers prioritize which issues to fix beyond the base image. Containers get created as soon as code is committed and can deploy just as quickly and the goal is to make sure those are secure containers from the get go. Snyk’s prioritization features focus developers attention on the most important issues, taking into account vulnerability details like severity, exploit maturity, and whether the container is actively running, together with filters that easily enable developers to decide which issues to fix and how to fix them.

Learn how Snyk Container customers handle cloud native application security

Red Ventures knew they needed to create a frictionless experience for developers if they wanted to improve their container security. That’s why they integrated Snyk with their tooling, surfacing actionable security issues and driving more efficient remediation. As a developer-first security tool, Snyk fits organically into their engineering workflows.

Lunar needed a solution that could be used right away, and didn’t require special training or separate web application to facilitate developer adoption. Implementing Snyk into their pipeline helps the team get a clearer picture of vulnerabilities across the board. This allows a busy team to see high level concerns and mitigate what’s most urgent at that time.