SJ Technologies partnered with Sonatype for the DevSecOps Community 2018 Survey. The survey was wildly popular, receiving answers from more than 2,000 respondents representing a wide range of industries, development practices, and responsibilities. One-third of respondents (33%) came from the technology industry, and banking and financial services was the second most represented group (15%). 70% of all respondents were using a container registry. With so many respondents utilizing containers, a deeper dive into container security is in order.
The numbers don't lie
Looking at year-over-year data, the percentage of respondents who reported using container and application security tooling doubled. In 2017, only 23% had tooling in place, compared to 56% in 2018. Container security is quickly becoming a segment ripe for standardization and simplification. Given the recent explosive growth of Kubernetes and the creation of new container runtimes in the past year, this should not come as a surprise.
What is surprising is the fact that most organizations are using more than one container registry. Most respondents use a private Docker registry, followed by AWS ECR and Sonatype Nexus. Red Hat OpenShift and Jfrog Artifactory were also well represented. One can imagine the many ways container registries could be utilized. But some registries are very different than others. Implementing security tooling with many registries could make for a convoluted pipeline if not thought through. Thankfully, most registries implement common APIs allowing for this.
When asked "Do you leverage security products to identify vulnerabilities in containers?" almost half of all respondents responded that they use security tooling to identify vulnerabilities in containers. When factoring in only results from respondents who consider themselves part of "mature DevOps processes," almost two-thirds are scanning containers for vulnerabilities. Another 25% are evaluating container security tooling. Yet one-quarter of all respondents stated they have no solution for identifying vulnerabilities in containers. That's somewhat terrifying in light of recent breaches.It's possible that there are two camps here: The first could be teams that are using containers tagged "latest" or that are continuously pulling from an assumed patched upstream. This isn't a good practice as organizations are trusting upstream to do security for them. The second, more likely camp includes organizations that don't have a solution for identifying vulnerabilities in containers. Given the adoption of containers, not scanning them for vulnerabilities leaves a dump truck-size hole in security processes.
Securing containers
There are some common misconceptions about container security. Liz Rice of Aqua Security points out, "I'd say the most common misconception is that containers are more like VMs than they are—and then being disappointed at the level of isolation they give you."
Containers are not virtual machines. With VMs, teams worried about the hypervisor and the OSes running underneath it. With containers, the model shifts to worrying about the kernel, container runtimes, and every package and framework in use in every container (in addition to the OS and hypervisor). With containers, development becomes drastically simpler and more consistent. But the number of security vulnerabilities needing to be addressed typically increases. Luckily, good container security processes allow for rapid mitigation of vulnerabilities. Containers require a different approach to security than VMs.
Processes: Update images instead of patching
Container lifespans should be much shorter than those of traditional VMs. Containers should be treated as immutable infrastructure. This is a mind-shift as much as it is a change in infrastructure. Containers should not be patched; they should be recreated. Updating container images and redeploying all affected containers is how container security is best applied. If the pipeline is built right, this process could be as simple as changing a tag in a configuration file.
Scanning for vulnerabilities in containers that are actively running is critical. But, as DevSecOps practitioners, always be shifting left. Scanning container registries for vulnerable images is a critical function as well. Scanning containers via version control actions should also be practiced. Containers should be lightweight enough to be scanned at every touchpoint. If there is a tool at your disposal to check for vulnerable containers running in a dev environment, use it! Scan early and scan often.
Open source tools for container security and scanning
The container security tool ecosystem continues to grow. One thing to keep in mind when building out a container security toolset: There is no one right way at the moment. Development pipelines are based off business needs. Implementing container security tooling will require an equal level of thought.
There are a number of open source tools available to help lock down containers, all of which we cannot cover in this article. But it wouldn't be a useful article without discussing a few tools. Using tools like AppArmor and seccomp is highly encouraged. Both are components of the Linux kernel and provide sane defaults. AppArmor applies mandatory access controls to running programs (like Docker itself). Seccomp restricts the actions (syscalls) available within a container. AppArmor and seccomp provide the minimum viable protection for systems and containers should a container become compromised. Neither will tell you that a piece of software contains vulnerabilities.
Several container registries offer a scanning tool. But if those don't cut it, there are other options. CoreOS offers a tool called Clair, an open source project for the static analysis of vulnerabilities in appc and Docker containers. Sysdig Falco is a behavioral activity monitor designed to detect anomalous activity in applications. Dagda (which incorporates Sysdig Falco) is a tool that performs static analysis of known vulnerabilities, trojans, viruses, malware, and other malicious threats in Docker images/containers. There are also CIS Benchmarks for Docker and Kubernetes (in addition to operating systems). These are just a handful of open source tools; there are numerous tools available to help secure containers and container environments.
Conclusion
The results of this year's DevSecOps Community Survey shows that container adoption will continue to grow. The need for greater visibility will increase as more containers enter an ecosystem. Container orchestration tools like Kubernetes will be adopted to help manage some of this need. As more software is layered into an ecosystem, more automation will make management less challenging. Automating security tooling into container-based workflows will become a critical piece of every major organization's security posture. Remember, always be shifting left.
This article was originally published on SJ Technologies Blog and is republished with permission.
[See our related story, Just say no to root (in containers)]
Comments are closed.