SJ Technologies partnered with Sonatype for the DevSecOps Community 2018 Survey. The survey was wildly standard, receiving solutions from greater than 2,000 respondents representing a variety of industries, growth practices, and obligations. One-third of respondents (33%) got here from the know-how trade, and banking and monetary companies was the second most represented group (15%). 70% of all respondents had been utilizing a container registry. With so many respondents using containers, a deeper dive into container safety is so as.
The numbers do not lie
Looking at year-over-year information, the proportion of respondents who reported utilizing container and software safety tooling doubled. In 2017, solely 23% had tooling in place, in comparison with 56% in 2018. Container safety is rapidly changing into a phase ripe for standardization and simplification. Given the latest explosive growth of Kubernetes and the creation of recent container runtimes prior to now 12 months, this could not come as a shock.
What is stunning is the truth that most organizations are utilizing multiple container registry. Most respondents use a personal Docker registry, adopted by AWS ECR and Sonatype Nexus. Red Hat OpenShift and Jfrog Artifactory had been additionally effectively represented. One can think about the various methods container registries might be utilized. But some registries are very totally different than others. Implementing safety tooling with many registries might make for a convoluted pipeline if not thought by means of. Thankfully, most registries implement frequent APIs permitting for this.
Containers require a unique strategy to safety than VMs.
When requested “Do you leverage security products to identify vulnerabilities in containers?” nearly half of all respondents responded that they use safety tooling to establish vulnerabilities in containers. When factoring in solely outcomes from respondents who contemplate themselves a part of “mature DevOps processes,” nearly two-thirds are scanning containers for vulnerabilities. Another 25% are evaluating container safety tooling. Yet one-quarter of all respondents acknowledged they haven’t any answer for figuring out vulnerabilities in containers. That’s considerably terrifying in gentle of latest breaches.
It’s attainable that there are two camps right here: The first might be groups which might be utilizing containers tagged “latest” or which might be constantly pulling from an assumed patched upstream. This is not a superb follow as organizations are trusting upstream to do safety for them. The second, extra probably camp consists of organizations that do not have an answer for figuring out vulnerabilities in containers. Given the adoption of containers, not scanning them for vulnerabilities leaves a dump truck-size gap in safety processes.
Securing containers
There are some frequent misconceptions about container safety. Liz Rice of Aqua Security factors 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 usually are not digital machines. With VMs, groups frightened concerning the hypervisor and the OSes operating beneath it. With containers, the mannequin shifts to worrying concerning the kernel, container runtimes, and each bundle and framework in use in each container (along with the OS and hypervisor). With containers, growth turns into drastically easier and extra constant. But the variety of safety vulnerabilities needing to be addressed sometimes will increase. Luckily, good container safety processes permit for speedy mitigation of vulnerabilities. Containers require a unique strategy to safety than VMs.
Processes: Update photos as an alternative of patching
Container lifespans ought to be a lot shorter than these of conventional VMs. Containers ought to be handled as immutable infrastructure. This is a mind-shift as a lot as it’s a change in infrastructure. Containers shouldn’t be patched; they need to be recreated. Updating container photos and redeploying all affected containers is how container safety is finest utilized. If the pipeline is constructed proper, this course of might be so simple as altering a tag in a configuration file.
Scanning for vulnerabilities in containers which might be actively operating is essential. But, as DevSecOps practitioners, at all times be shifting left. Scanning container registries for susceptible photos is a essential operate as effectively. Scanning containers by way of model management actions must also be practiced. Containers ought to be light-weight sufficient to be scanned at each touchpoint. If there’s a software at your disposal to examine for susceptible containers operating in a dev surroundings, use it! Scan early and scan typically.
Open supply instruments for container safety and scanning
The container safety software ecosystem continues to develop. One factor to bear in mind when constructing out a container safety toolset: There is nobody proper approach for the time being. Development pipelines are primarily based off enterprise wants. Implementing container safety tooling would require an equal degree of thought.
There are numerous open supply instruments accessible to assist lock down containers, all of which we can’t cowl on this article. But it would not be a helpful article with out discussing a couple of instruments. Using instruments like AppArmor and seccomp is very inspired. Both are parts of the Linux kernel and supply sane defaults. AppArmor applies obligatory entry controls to operating packages (like Docker itself). Seccomp restricts the actions (syscalls) accessible inside a container. AppArmor and seccomp present the minimal viable safety for programs and containers ought to a container grow to be compromised. Neither will let you know that a piece of software program accommodates vulnerabilities.
Several container registries provide a scanning software. But if these do not reduce it, there are different choices. CoreOS affords a software referred to as Clair, an open supply mission for the static evaluation of vulnerabilities in appc and Docker containers. Sysdig Falco is a behavioral exercise monitor designed to detect anomalous exercise in functions. Dagda (which contains Sysdig Falco) is a software that performs static evaluation of recognized vulnerabilities, trojans, viruses, malware, and different malicious threats in Docker photos/containers. There are additionally CIS Benchmarks for Docker and Kubernetes (along with working programs). These are only a handful of open supply instruments; there are quite a few instruments accessible to assist safe containers and container environments.
Conclusion
The outcomes of this 12 months’s DevSecOps Community Survey exhibits that container adoption will proceed to develop. The want for higher visibility will improve as extra containers enter an ecosystem. Container orchestration instruments like Kubernetes shall be adopted to assist handle a few of this want. As extra software program is layered into an ecosystem, extra automation will make administration much less difficult. Automating safety tooling into container-based workflows will grow to be a essential piece of each main group’s safety posture. Remember, at all times be shifting left.
This article was initially printed on SJ Technologies Blog and is republished with permission.
[See our associated story, Just say no to root (in containers)]