Skip to content

CL-0014: Logging driver set to none

Severity: LOW

Derivation (see severity model):

  • Baseline: A — the attacker already has code execution in this container, as the workload uid
  • Precondition: Removes a mitigation — discarding the runtime log stream grants the attacker nothing. It deletes the evidence an investigator would otherwise have
  • Impact: Single container — only this service's stdout and stderr are discarded
  • Qualifier/modifier: none
  • Derived: Removes a mitigation × Single container = LOW
  • Shipped: LOW
  • Evidence: Captured observation, no premise check yet: under --log-driver none, docker logs on a container that wrote to stdout returns Error response from daemon: configured logging driver does not support reading, where the default driver returns the line (Docker 29.1.3)

References: - Docker logging drivers — none driver disables collection - OWASP Logging Cheat Sheet

What it detects

Services with logging.driver set to none. Services using any other driver (e.g., json-file, syslog, fluentd) or services without explicit logging configuration are not flagged.

Why it matters

logging.driver: none discards the container's stdout/stderr at the daemon — docker logs, log shippers reading the JSON-file driver, and any centralized aggregator that relies on the runtime see nothing. Application-level logging that writes to a file or remote endpoint is unaffected, but the runtime-level forensic data source is gone. During an incident, anything the workload only emitted on stdout is lost.

This is a forensic gap, not a non-repudiation guarantee — runtime logs are not authenticated or tamper-evident regardless. The cost of recovery during an investigation is the actual harm.

Fix

Remove driver: none to use the default logging driver, or configure an appropriate one:

# Before
services:
  app:
    image: myapp:1.0
    logging:
      driver: none

# After
services:
  app:
    image: myapp:1.0
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: '3'

For centralized logging, use syslog, fluentd, or gelf drivers with appropriate endpoints.

ATT&CK coverage

Remediating this finding contributes to mitigating the following MITRE ATT&CK techniques (pinned to ATT&CK v18). compose-lint is a static analyser, so this is mitigation coverage — it detects nothing at runtime.

Technique Tactic
T1070 Indicator Removal Stealth