<p>Larger organizations are concerned that containers introduce more security risks than traditional VMs as there isn't any hypervisor segregation. Developers running arbitrary images, that run as root, that they don't bother to security patch, looks worse for security team's than automatically patched VMs controlled by ops teams without containers.</p>

<p>Misconfiguration of docker demon itself can also introduce security risks. It's fairly common for complex software to have security tuning tools and to run them as part of ”operational readiness checks” of the live environment before going live as a security audit. Then also run them on some periodic cycle or after any major upgrades of the software that is being audited. The tools you name will be very useful for that purpose. </p>

<p>Software vendors who build container orchestrators are actively working in removing any dependency on needing to run docker demon see <a href="https://cri-o.io" rel="nofollow noreferrer">cri-o.io</a>. Security, footprint and fork time are areas that vendors are competing on. CoreOS was a big innovator in this space before they were acquired you can look at some of their architecture presentations to get a flavor of what containers at scale workout docker looks like.</p>

<p>From a devops perspective we should empower devs to run security tools all the time to fix issues early. In practice devs might be using Docker for Windows locally but the live env would be a container orchestrator possibly running <a href="https://coreos.com/rkt/docs/latest/using-rkt-with-kubernetes.html" rel="nofollow noreferrer">rkt</a>. In reality devs in large organizations are not going to security scan infrastructure they didn't create and dont have root on. Even at a startup not every dev can be familiar with all of the tooling and software running in production. An external security audit is a smart investment. </p>

<p>IMHO if your teaching containers from a developer perspective it's worth pointing out such tools. Certainly devs in my experience are woefully unaware that running containers they find on docker hub as root isn't the smartest way to be secure. I would only expect to see such tools to be covered in depth by courses teaching security analysts how to audit systems that use Docker. </p>

CC BY-SA 4.0
2019-02-04T11:01:30.903Z
Thanks, @simbo1905. I'm bound to Docker. However: _"if your teaching containers from a developer perspective it's worth pointing out such tools."_ That was more or less what I planned to do. Showing early in the course curriculum how we can escalate privileges with something along the lines of [Root your Docker host](https://www.electricmonk.nl/log/2017/09/30/root-your-docker-host-in-10-seconds-for-fun-and-profit/) and how to audit a host using `docker-bench-security`. It is not much, but at least that should make my students aware of the security issues involved in running Docker.
Sylvain Leroux
CC BY-SA 4.0
2019-02-04T08:19:24.800Z
2019-02-04T22:17:42.483Z
2019-02-04T22:17:42.483Z
simbo1905
<p>Docker Bench is a scripted report of many of the CIS recommendations (at least those that can be scripted. Various organizations use the CIS recommendations as a starting point for their security policy, the goal is to have a recognized organization provide the best practices. This is useful when dealing with auditors in regulated environments since a company can often show what they've done towards the CIS recommendations to quickly get through most of the audit (the auditors will be familiar with the CIS recommendations).</p>

<p>That said, I personally feel the advice from CIS is a mixed bag when dealing with Docker. Some of the suggestions look like a copy and paste from advice given to security physical bare metal systems, rather than a sandboxed application. And some of the recommended practices, weird things like avoiding the use of <code>ADD</code> in a Dockerfile, have little security reasoning (anything you can include with an <code>ADD</code> of a tar you could include with a <code>COPY</code> of a full directory) and will flag just about every image you are running since <code>ADD</code> is used as the first step of nearly every base image. There's a list of other advice they give that has little to nothing to do with security and is just a recommended configuration setting that cannot be applied in all environments.</p>

<p>What's lacking with CIS recommendations for Docker is actually securing the applications running inside of the container. This gets out of scope since you can run anything in a container, and they often have other recommendations that cover this. However, I think it's important since many of the security exploits using containers have nothing to do with docker but rather running vulnerable applications in docker.</p>

<p>Because of this, my advice is to start with CIS but then adapt it for your own environment, remove the advice has little security benefit, and add in recommendations that can help secure the environment for your own use case.</p>

CC BY-SA 4.0
2019-02-04T16:36:21.857Z
Thanks, Brandon. As always, that's an enlightening answer, and I think I got the point in following the CIS recommendations to harden the actual production environment. But I also had educational aspects in mind while asking this question. From what you said, Docker Bench is not necessarily the best tool to raise new users awareness about the risks associated with running Docker without any safety precautions. Maybe would you have something else to suggest that would better suit that need?
Sylvain Leroux
CC BY-SA 4.0
2019-02-04T17:06:14.623Z
I finally chose to ask another question specifically [focusing on the "educational" aspects](https://devops.stackexchange.com/questions/6223/how-to-raise-awareness-about-the-security-risk-involved-with-running-docker) since the current question has already obtained two very good answers.
Sylvain Leroux
CC BY-SA 4.0
2019-02-04T22:14:01.790Z
Today I was on a call about dev teams being swamped by security scanning reports and then effectively ignoring them when they see a number of false positives or things that are out of their control. This reinforces to me that information isn’t knowledge. I was lucky enough to work with one of the authors of a book https://www.amazon.co.uk/Agile-Application-Security-Laura-Bell/dp/1491938846 that has a lot of advice that aligns to devops. Well worth a read to understand where security tools fit in with devops behaviours.
simbo1905
CC BY-SA 4.0
2019-02-04T13:18:17.750Z
2019-02-04T13:18:17.750Z
BMitch
<p>I just learned about <a href="https://github.com/docker/docker-bench-security" rel="nofollow noreferrer">Docker Bench for Security</a> and <a href="https://www.cisecurity.org/benchmark/docker/" rel="nofollow noreferrer">CIS Benchmark for Docker Community Edition</a>.</p>

<p>Why, how and when am I supposed to use these tools?</p>

<docker><devsecops>
CIS Benchmark for Docker and Docker Bench for Security: why, how and when?
Sylvain Leroux
# CIS Benchmark for Docker and Docker Bench for Security: why, how and when?

(Asked by: username_0 on 2019-02-03)

I just learned about [Docker Bench for Security](https://github.com/docker/docker-bench-security) and [CIS Benchmark for Docker Community Edition](https://www.cisecurity.org/benchmark/docker/).

Why, how and when am I supposed to use these tools?

**Tags:** docker, devsecops


---

## 2 answers

### Answer by username_1 on 2019-02-04. Score: 1 | Accepted answer

Larger organizations are concerned that containers introduce more security risks than traditional VMs as there isn't any hypervisor segregation. Developers running arbitrary images, that run as root, that they don't bother to security patch, looks worse for security team's than automatically patched VMs controlled by ops teams without containers.

Misconfiguration of docker demon itself can also introduce security risks. It's fairly common for complex software to have security tuning tools and to run them as part of ”operational readiness checks” of the live environment before going live as a security audit. Then also run them on some periodic cycle or after any major upgrades of the software that is being audited. The tools you name will be very useful for that purpose.

Software vendors who build container orchestrators are actively working in removing any dependency on needing to run docker demon see [cri-o.io](https://cri-o.io). Security, footprint and fork time are areas that vendors are competing on. CoreOS was a big innovator in this space before they were acquired you can look at some of their architecture presentations to get a flavor of what containers at scale workout docker looks like.

From a devops perspective we should empower devs to run security tools all the time to fix issues early. In practice devs might be using Docker for Windows locally but the live env would be a container orchestrator possibly running [rkt](https://coreos.com/rkt/docs/latest/using-rkt-with-kubernetes.html). In reality devs in large organizations are not going to security scan infrastructure they didn't create and dont have root on. Even at a startup not every dev can be familiar with all of the tooling and software running in production. An external security audit is a smart investment.

IMHO if your teaching containers from a developer perspective it's worth pointing out such tools. Certainly devs in my experience are woefully unaware that running containers they find on docker hub as root isn't the smartest way to be secure. I would only expect to see such tools to be covered in depth by courses teaching security analysts how to audit systems that use Docker.

> **Comments:**
> **username_0**: Thanks, @username_1. I'm bound to Docker. However: _"if your teaching containers from a developer perspective it's worth pointing out such tools."_ That was more or less what I planned to do. Showing early in the course curriculum how we can escalate privileges with something along the lines of [Root your Docker host](https://www.electricmonk.nl/log/2017/09/30/root-your-docker-host-in-10-seconds-for-fun-and-profit/) and how to audit a host using `docker-bench-security`. It is not much, but at least that should make my students aware of the security issues involved in running Docker.  

---

### Answer by username_2 on 2019-02-04. Score: 1

Docker Bench is a scripted report of many of the CIS recommendations (at least those that can be scripted. Various organizations use the CIS recommendations as a starting point for their security policy, the goal is to have a recognized organization provide the best practices. This is useful when dealing with auditors in regulated environments since a company can often show what they've done towards the CIS recommendations to quickly get through most of the audit (the auditors will be familiar with the CIS recommendations).

That said, I personally feel the advice from CIS is a mixed bag when dealing with Docker. Some of the suggestions look like a copy and paste from advice given to security physical bare metal systems, rather than a sandboxed application. And some of the recommended practices, weird things like avoiding the use of `ADD` in a Dockerfile, have little security reasoning (anything you can include with an `ADD` of a tar you could include with a `COPY` of a full directory) and will flag just about every image you are running since `ADD` is used as the first step of nearly every base image. There's a list of other advice they give that has little to nothing to do with security and is just a recommended configuration setting that cannot be applied in all environments.

What's lacking with CIS recommendations for Docker is actually securing the applications running inside of the container. This gets out of scope since you can run anything in a container, and they often have other recommendations that cover this. However, I think it's important since many of the security exploits using containers have nothing to do with docker but rather running vulnerable applications in docker.

Because of this, my advice is to start with CIS but then adapt it for your own environment, remove the advice has little security benefit, and add in recommendations that can help secure the environment for your own use case.

> **Comments:**
> **username_0**: Thanks, Brandon. As always, that's an enlightening answer, and I think I got the point in following the CIS recommendations to harden the actual production environment. But I also had educational aspects in mind while asking this question. From what you said, Docker Bench is not necessarily the best tool to raise new users awareness about the risks associated with running Docker without any safety precautions. Maybe would you have something else to suggest that would better suit that need?  
> **username_0**: I finally chose to ask another question specifically [focusing on the "educational" aspects](https://devops.stackexchange.com/questions/6223/how-to-raise-awareness-about-the-security-risk-involved-with-running-docker) since the current question has already obtained two very good answers.  
> **username_1**: Today I was on a call about dev teams being swamped by security scanning reports and then effectively ignoring them when they see a number of false positives or things that are out of their control. This reinforces to me that information isn’t knowledge. I was lucky enough to work with one of the authors of a book https://www.amazon.co.uk/Agile-Application-Security-Laura-Bell/dp/1491938846 that has a lot of advice that aligns to devops. Well worth a read to understand where security tools fit in with devops behaviours.  

---

