Guardrails for docker-compose.yml.

Why

Compose files grow organically. A single line like privileged: true or mounting /var/run/docker.sock can silently turn a container into “root on host”. ConfigSentry surfaces the riskiest patterns early.

60-second quickstart

Local scan:

npx configsentry ./docker-compose.yml

Adopt incrementally (existing repo): generate a baseline once, commit it, then block only on new findings.

# generate baseline (non-blocking)
npx configsentry ./docker-compose.yml --write-baseline .configsentry-baseline.json

# CI: suppress baseline findings
npx configsentry ./docker-compose.yml --baseline .configsentry-baseline.json

Optional: fail only on HIGH severity (CI gating):

npx configsentry ./docker-compose.yml --severity-threshold high

Details: baselines docs

GitHub Action + Code Scanning (SARIF)

permissions:
  contents: read
  security-events: write

- uses: alfredMorgenstern/configsentry@v0.0.28
  with:
    target: .
    sarif: true
    upload-sarif: true
    # baseline: .configsentry-baseline.json
    # fail-on-findings: false

More: Action usage

Popular pages

Docker Compose linter Compose security best practices GitHub Code Scanning (SARIF)

What it checks

• Root containers
  Flags when user: is missing.
• Hardcoded secrets
  Flags likely secrets in environment: (heuristic).
• docker.sock mounts
  Flags mounting /var/run/docker.sock.
• Exposed sensitive ports
  Flags e.g. 5432:5432 on all interfaces.
• Unpinned images
  Flags image: nginx / :latest.
• Healthchecks + restart
  Encourages safer defaults for reliability.

Proof in the wild

ConfigSentry is tested against public repositories (treated as untrusted, no repo code executed). Reports are published here:

Public repo tests →

Blog

Short, practical notes: baselines, CI gating, and Compose security footguns.

Read the blog →