>_ DevTrendsen

Language

Home

Languages

Sections

Frontend Backend Mobile DevOps AI / ML GameDev Blockchain Embedded Security
Go

How to check Docker container security without extra headaches

DockerScan Logo

Recently, security researchers found over four million empty placeholder containers and hundreds of thousands of images with hidden cryptominers on Docker Hub. We have gotten used to pulling base images or third-party dependencies with a single docker pull command, rarely thinking about what might be hidden inside layers — not just a vulnerable package, but an embedded access token to someone else's infrastructure or a sandbox escape script.

For image scanning, people usually turn to Trivy, Grype, or Clair. They do a decent job finding known CVEs in system packages, but often miss subtle things like poor runtime configuration, leaked API keys, and fresh attack vectors targeting supply chains.

The dockerscan project by Spanish security researcher Daniel Garcia (cr0hn) solves this problem with comprehensive auditing. The first version of the tool was written in Python back in 2017 and ran slowly, but in the second version the author completely rewrote the engine in Go, increased speed tenfold, and combined vulnerability scanning, secret detection, and configuration auditing into a single binary.

What's inside the new DockerScan

Instead of running three different utilities in sequence to check images, dockerscan runs comprehensive diagnostics across multiple areas at once.

The tool combines five analysis modules:

  • CIS Docker Benchmark v1.7.0. Checks over 80 security parameters, including running as root, unnecessary open ports, missing HEALTHCHECK directive, and correct system file permissions.
  • Supply chain attack detector. Looks for traces of popular campaigns from recent years: hidden miners (like xmrig), backdoors in system libraries (following the xz-utils incident), phishing text, and containers without real layers.
  • Embedded secrets detection. Recognizes over 40 key and token formats (AWS, GCP, OpenAI, Stripe, private SSH keys, database connection strings). Unknown tokens are caught through Shannon entropy calculation with a threshold above 4.5.
  • CVE vulnerability database. Tracks dangerous container escape vulnerabilities (CVE-2024-21626 in runc), BuildKit issues, and outdated base images. The database is compiled from the official MITRE cvelistV5 snapshot, so the utility doesn't hit NVD API limits.
  • Runtime security auditing. Checks dangerous Linux capabilities (for example, CAP_SYS_ADMIN), Seccomp and AppArmor profiles, and namespace isolation flags.

In version 2.1.0, the author fixed an important bug in previous v2.0.x builds that caused package vulnerability scanning to silently return zero findings. Now package version matching follows dpkg rules accounting for distribution backports.

Quick start and running checks

The utility is distributed as a ready-to-use binary for Linux, macOS, and Windows. No dependencies to pull.

Installation on Linux amd64 takes three lines:

curl -L https://github.com/cr0hn/dockerscan/releases/latest/download/dockerscan-linux-amd64 -o dockerscan
chmod +x dockerscan
sudo mv dockerscan /usr/local/bin/

Before the first run, download the local CVE database:

dockerscan update-db

The database is updated daily via GitHub Actions and weighs about 30 MB compressed. After that, you can point the scanner at any local or remote image:

dockerscan nginx:latest

If you're only interested in specific checks, for example secret detection and CIS Benchmark compliance, you can limit modules with the --scanners flag:

dockerscan --scanners cis,secrets ubuntu:22.04

For automation scripts, the quiet mode -q and severity filtering come in handy:

dockerscan -q --only-critical my-app:prod

Working with private registries

A common issue with many scanners is inconvenient authentication with private repositories. Dockerscan supports all popular scenarios: Docker Hub, GHCR, AWS ECR, Google Artifact Registry, Azure ACR, and GitLab.

If you're already authenticated via docker login, the utility automatically pulls tokens from ~/.docker/config.json. It also supports system credential helpers (osxkeychain on macOS, wincred on Windows, and pass on Linux).

For CI/CD pipelines, it's more convenient to pass credentials via environment variables:

export DOCKER_USERNAME=ci-bot
export DOCKER_PASSWORD=ghp_secret_token_here
dockerscan ghcr.io/my-org/private-service:v1.2.0

The utility returns clear exit codes: 0 for a clean report, 1 when High-level issues are found, and 2 when critical vulnerabilities are detected. This allows stopping the pipeline build immediately upon finding a dangerous bug.

Integrating into CI/CD and reporting

Dockerscan results are saved in JSON and SARIF formats. The SARIF format is natively understood by GitHub Security, GitLab, and Azure DevOps, so found issues are immediately displayed in the pull request interface.

Example step for GitHub Actions:

name: Security Scan
  run: |
    ./dockerscan update-db
    ./dockerscan -q myapp:${{ github.sha }}

name: Upload SARIF report
  uses: github/codeql-action/upload-sarif@v2
  if: always()
  with:
    sarif_file: dockerscan-report.sarif

License and limitations

The project license deserves special attention. The author chose a Source-Available model. The source code is fully open, the utility can be used for free for internal company needs, embedded in personal CI/CD pipelines, and used in audits and pentests. Only one thing is prohibited: packaging dockerscan into a commercial SaaS and selling it as a paid cloud scanning service without the author's permission.

Is it worth switching to DockerScan

If you need fast static analysis of images combined with container permission checks and leaked token detection, dockerscan covers all these tasks with a single command. The utility consumes about 50-100 MB of RAM and runs noticeably faster than old Python solutions.

The tool is a great fit for DevOps engineers and security specialists for regular production image auditing and adding strict checks to deployment pipelines. The best way to get started is to run it against a couple of your own working containers to see the real number of hidden CIS Benchmark warnings.

Related projects