The blog post was written by:
Chris Short (@ChrisShort)
Senior DevOps Advocate
The Numbers Don't Lie
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 hole in security processes.
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.
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. 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 Kuberenetes (in addition to operating systems). These are just a handful of open source tools. Needless to say, there are numerous tools available to help secure containers and container environments.