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 using advanced technology solutions which prevent security issues from the stage of coding. For example, Snyk can now automate fix PRs for containers and elevate Dockerfiles to first-class status in your git repos.
How One AI-Driven Media Platform Cut EBS Costs for AWS ASGs by 48%
Why runtime container security isn’t used by developers
Most developers 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. 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 to truly “shift left” to secure containers
It really takes a solution built from the ground up to make security part of a developers’ everyday thinking and build processes. Merely presenting a long list of vulnerabilities, as typical in security-minded tools, doesn’t cut it.
There aren’t many tools there to help. Snyk can guide developers how to fix container issues, starting with 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. It is agnostic when it comes to how you choose to run your containers. No sidecars, no agents, and no special privileged pods to run in Kubernetes are needed to get this to work.
Scaling security as container usage grows
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.
Keep the capabilities. Lose the vulnerabilities. Contact us to implement end-to-end code security, to let your teams code worry-free.
Originally published by Snyk.
