Looking at year over year data for the DevSecOps Community Survey, the percentage of respondents stating Container and Application Security tooling is in use doubled. In 2017, only 23% had tooling in place wherein 2018, 56% responded as having Container and Application Security tooling in place. 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 were using more than one container registry. Most respondents are using a private Docker registry followed by AWS ECR and Sonatype Nexus. Red Hat OpenShift and Jfrog Artifactory were well represented too. 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 are using security tooling to identify vulnerabilities in containers. When factoring in only results from respondents considering themselves part of "Mature DevOps Processes" almost two-thirds are scanning containers for vulnerabilities. Another quarter are evaluating container security tooling. Yet a quarter of all respondents stated they have no solution for identifying vulnerabilities in containers.

That's somewhat terrifying in-light of recent breaches. It could be there are two camps here. The first camp could be teams that are using containers tagged "latest" or 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 other, and more likely, camp are 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 whole in security processes.

Securing Containers

There are some very 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 goes up. Luckily, good container security processes, allow for rapid mitigation of vulnerabilities. Containers require a different approach to security than VMs.

Processes

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.

Tooling

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 need an equal level of thought.

There are a number of open source tools available to help lockdown containers. All of them cannot be covered in this article. But, it wouldn't be a useful article to 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. Clair is an open source project for the static analysis of vulnerabilities in appc and docker containers. Sonatype’s Nexus Lifecycle analyzes the application layer of containers for known open source vulnerabilities.  Sysdig Falco is a behavioral activity monitor designed to detect anomalous activity in applications. Dagda (which incorporates Sysdig Falco) is a tool to perform static analysis of known vulnerabilities, trojans, viruses, malware & other malicious threats in Docker images/containers. There are also CIS Benchmarks for Docker and Kubernetes (in addition to operating systems). Needless to say, 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.

Finally, I encourage you to read this year’s full set of responses from the 2018 DevSecOps Community Survey here.  The results are fascinating.