docker-bench-security

The Docker Bench for Security is a script that checks for dozens of common best-practices around deploying Docker containers in production.

9,097

1,011

9,097

View on GitHub

Top Related Projects

trivy

22,801

Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more

grype

8,441

A vulnerability scanner for container images and filesystems

dockle

2,768

Container Image Linter for Security, Helping build the Best-Practice Docker Image, Easy to start

clair

10,257

Vulnerability Static Analysis for Containers

Quick Overview

Docker Bench for Security is an automated testing tool that checks for dozens of common best-practices around deploying Docker containers in production. It is a script that checks for common best-practices around deploying Docker containers in production. The tests are all automated, and are inspired by the CIS Docker Benchmark v1.2.0.

Pros

Comprehensive security checks based on industry standards
Easy to run and integrate into CI/CD pipelines
Regularly updated to reflect the latest Docker security best practices
Provides clear, actionable output for improving container security

Cons

May produce false positives in some environments
Requires root access to run, which can be a security concern
Some checks may not be applicable to all Docker deployments
Can be overwhelming for beginners due to the large number of checks

Getting Started

To get started with Docker Bench for Security, follow these steps:

Clone the repository:

git clone https://github.com/docker/docker-bench-security.git

Change to the docker-bench-security directory:
```
cd docker-bench-security
```
Run the script:
```
sudo sh docker-bench-security.sh
```

The script will run and provide a detailed output of security checks and recommendations for your Docker environment.

Competitor Comparisons

trivy

22,801

Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more

Pros of Trivy

Broader scope: Scans containers, filesystems, git repositories, and more
Faster scanning speed due to efficient caching mechanisms
Integrates with various CI/CD tools and platforms

Cons of Trivy

May require more setup and configuration for specific use cases
Can produce more verbose output, potentially overwhelming for beginners

Code Comparison

Docker Bench Security:

#!/bin/sh
# Docker Bench for Security v1.3.4
# Check for existence of required binaries
for executable in docker grep awk sed; do
    if ! command -v "$executable" > /dev/null 2>&1; then
        echo "[-] This script requires ${executable} to be installed"

Trivy:

func (s Scanner) Scan(ctx context.Context, target string, artifactKey string, options types.ScanOptions) (types.Report, error) {
    scanners, err := s.InitScanners(ctx, target, options)
    if err != nil {
        return types.Report{}, xerrors.Errorf("unable to initialize scanners: %w", err)
    }

Docker Bench Security focuses on Docker-specific security checks using shell scripts, while Trivy is written in Go and offers a more comprehensive scanning approach for various artifacts. Trivy's code structure allows for easier extensibility and integration with other tools.

grype

8,441

A vulnerability scanner for container images and filesystems

Pros of Grype

Focuses on vulnerability scanning for container images and filesystems
Supports multiple operating systems and package formats
Regularly updated vulnerability database

Cons of Grype

Limited to vulnerability scanning, doesn't cover broader security checks
Requires integration with other tools for comprehensive container security

Code Comparison

Docker Bench Security:

#!/bin/sh
# Docker Bench for Security v1.3.4
# Check for existence of required binaries
check_required_binaries() {
  for cmd in "$@"; do
    if ! command -v "$cmd" >/dev/null 2>&1; then
      echo "ERROR: $cmd binary not found, exiting."
      exit 1
    fi
  done
}

Grype:

func main() {
	cmd.New().Execute()
}

func (r *rootCmd) Execute() {
	if err := r.cmd.Execute(); err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
}

Docker Bench Security is a shell script that performs various security checks on Docker installations, while Grype is a Go-based tool specifically designed for vulnerability scanning. Docker Bench Security covers a broader range of security aspects but is limited to Docker, whereas Grype focuses on vulnerability detection across various container formats and filesystems.

dockle

2,768

Container Image Linter for Security, Helping build the Best-Practice Docker Image, Easy to start

Pros of Dockle

Faster scanning speed due to its lightweight nature
Provides a more comprehensive set of checks, including CIS benchmarks
Offers both CLI and container-based usage for flexibility

Cons of Dockle

Less mature project with potentially fewer community contributions
May have a steeper learning curve for users familiar with Docker Bench Security

Code Comparison

Dockle:

dockle --exit-code 1 --exit-level fatal myimage:latest

Docker Bench Security:

docker run -it --net host --pid host --userns host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

Key Differences

Dockle focuses on container image scanning, while Docker Bench Security covers a broader range of Docker security aspects
Dockle provides a simpler command-line interface, making it easier to integrate into CI/CD pipelines
Docker Bench Security is more closely aligned with official Docker security best practices

Both tools serve valuable purposes in container security, with Dockle offering a more streamlined approach to image scanning and Docker Bench Security providing a comprehensive security assessment of the Docker environment.

clair

10,257

Vulnerability Static Analysis for Containers

Pros of Clair

Provides continuous vulnerability scanning for container images
Supports multiple operating systems and package managers
Offers a more comprehensive and up-to-date vulnerability database

Cons of Clair

More complex setup and configuration compared to Docker Bench Security
Requires additional infrastructure to run effectively
May generate more false positives due to its extensive scanning capabilities

Code Comparison

Docker Bench Security:

#!/bin/sh
# Docker Bench for Security v1.3.4
# Check for existence of required binaries
for executable in docker grep awk sed; do
    if ! command -v "$executable" > /dev/null 2>&1; then
        echo "This script requires ${executable} to be installed"

Clair:

func main() {
    // Parse command-line arguments
    flag.Parse()

    // Initialize the application
    app, err := clair.New(config)
    if err != nil {
        log.Fatal(err)
    }

While Docker Bench Security is a shell script focused on auditing Docker installations, Clair is a Go application designed for continuous vulnerability scanning of container images. Docker Bench Security is simpler to use but less comprehensive, while Clair offers more extensive scanning capabilities at the cost of increased complexity.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Docker Bench for Security

Docker Bench for Security running

The Docker Bench for Security is a script that checks for dozens of common best-practices around deploying Docker containers in production. The tests are all automated, and are based on the CIS Docker Benchmark v1.6.0.

We are making this available as an open-source utility so the Docker community can have an easy way to self-assess their hosts and Docker containers against this benchmark.

Release	CIS
1.6.0	1.6.0
1.5.0	1.5.0
1.3.6	1.4.0
1.3.5	1.2.0
1.3.3	1.1.0
1.3.0	1.13.0

Running Docker Bench for Security

Run from your base host

You can simply run this script from your base host by running:

git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
sudo sh docker-bench-security.sh

Note: jq is an optional but recommended dependency.

Run with Docker

Building Docker image

You have two options if you wish to build and run this container yourself:

Use Docker Build:

git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
docker build --no-cache -t docker-bench-security .

Followed by an appropriate docker run command as stated below.

Use Docker Compose:

git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
docker-compose run --rm docker-bench-security

Please note that the docker/docker-bench-security image is out-of-date and and a manual build is required. See #405 for more information.

Note that this container is being run with a lot of privilege -- sharing the host's filesystem, pid and network namespaces, due to portions of the benchmark applying to the running host.

Using the container

docker run --rm --net host --pid host --userns host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /etc:/etc:ro \
    -v /usr/bin/containerd:/usr/bin/containerd:ro \
    -v /usr/bin/runc:/usr/bin/runc:ro \
    -v /usr/lib/systemd:/usr/lib/systemd:ro \
    -v /var/lib:/var/lib:ro \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    --label docker_bench_security \
    docker-bench-security

Don't forget to adjust the shared volumes according to your operating system. Some examples are:

On Ubuntu the docker.service and docker.secret files are located in /lib/systemd/system folder by default.

docker run --rm --net host --pid host --userns host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /etc:/etc:ro \
    -v /lib/systemd/system:/lib/systemd/system:ro \
    -v /usr/bin/containerd:/usr/bin/containerd:ro \
    -v /usr/bin/runc:/usr/bin/runc:ro \
    -v /usr/lib/systemd:/usr/lib/systemd:ro \
    -v /var/lib:/var/lib:ro \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    --label docker_bench_security \
    docker-bench-security

The /etc/hostname file is missing on macOS, so it will need to be created first. Also, Docker Desktop on macOS doesn't have /usr/lib/systemd or the above Docker binaries.

sudo touch /etc/hostname

docker run --rm --net host --pid host --userns host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /etc:/etc \
    -v /var/lib:/var/lib:ro \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    --label docker_bench_security \
    docker-bench-security

Note

Docker bench requires Docker 1.13.0 or later in order to run.

Note that when distributions don't contain auditctl, the audit tests will check /etc/audit/audit.rules to see if a rule is present instead.

Docker Bench for Security options

  -b           optional  Do not print colors
  -h           optional  Print this help message
  -l FILE      optional  Log output in FILE, inside container if run using docker
  -u USERS     optional  Comma delimited list of trusted docker user(s)
  -c CHECK     optional  Comma delimited list of specific check(s) id
  -e CHECK     optional  Comma delimited list of specific check(s) id to exclude
  -i INCLUDE   optional  Comma delimited list of patterns within a container or image name to check
  -x EXCLUDE   optional  Comma delimited list of patterns within a container or image name to exclude from check
  -t LABEL     optional  Comma delimited list of labels within a container or image to check
  -n LIMIT     optional  In JSON output, when reporting lists of items (containers, images, etc.), limit the number of reported items to LIMIT. Default 0 (no limit).
  -p PRINT     optional  Disable the printing of remediation measures. Default: print remediation measures.

By default the Docker Bench for Security script will run all available CIS tests and produce logs in the log folder from current directory, named docker-bench-security.log.json and docker-bench-security.log.

If the docker container is used then the log files will be created inside the container in location /usr/local/bin/log/. If you wish to access them from the host after the container has been run you will need to mount a volume for storing them in.

The CIS based checks are named check_<section>_<number>, e.g. check_2_6 and community contributed checks are named check_c_<number>.

sh docker-bench-security.sh -c check_2_2 will only run check 2.2 Ensure the logging level is set to 'info'.

sh docker-bench-security.sh -e check_2_2 will run all available checks except 2.2 Ensure the logging level is set to 'info'.

sh docker-bench-security.sh -e docker_enterprise_configuration will run all available checks except the docker_enterprise_configuration group

sh docker-bench-security.sh -e docker_enterprise_configuration,check_2_2 will run all available checks except the docker_enterprise_configuration group and 2.2 Ensure the logging level is set to 'info'

sh docker-bench-security.sh -c container_images,container_runtime will run just the container_images and container_runtime checks

sh docker-bench-security.sh -c container_images -e check_4_5 will run just the container_images checks except 4.5 Ensure Content trust for Docker is Enabled

Note that when submitting checks, provide information why it is a reasonable test to add and please include some kind of official documentation verifying that information.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot