Коротко: Контейнерный аудит зрелый только тогда, когда связывает build-time и runtime: какой base image, кто root, какие capabilities, какие секреты, какие volumes и какие network policies.
Проблема
Контейнер может иметь мало CVE, но запускаться от root, иметь лишние capabilities, writable filesystem и секреты в environment.
И наоборот: образ может показывать много CVE, но часть из них не достижима в runtime. Без контекста команда чинит не то.
Решение
Проверка должна объединять SBOM, vulnerability scan, Dockerfile/IaC review, secret scan и runtime baseline.
В отчёте нужно показывать конкретный hardening diff: non-root, read-only fs, drop capabilities, pinned base image, secrets via vault/secret manager.
Что проверить руками
- Проверить Dockerfile на USER, pinned tag/digest, package cleanup.
- Проверить compose/k8s на privileged, hostPath, hostNetwork, capabilities.
- Сравнить scan results с runtime exposure.
- Собрать минимальный retest: новый image digest и hardened runtime config.
Безопасный пример кода
Hardened service profile для review. Пример рассчитан на owned/lab-среду и не выполняет вредоносных действий.
services:
app:
image: registry.example/app@sha256:REPLACE_WITH_DIGEST
read_only: true
cap_drop:
- ALL
security_opt:
- no-new-privileges:true
user: "10001:10001"
tmpfs:
- /tmp:size=64m,mode=1777
environment:
APP_ENV: production
# Secrets are mounted from the platform, not committed into compose files.Как это должно попасть в отчёт
- Evidence: image digest, Dockerfile checks, IaC findings, runtime settings.
- Business impact: container escape probability, data exposure, lateral movement.
- Retest: hardened deployment passes scan and service health checks.
Этическая рамка: материал предназначен для defensive security, аудита собственных систем, обучения и подготовки remediation. Он не содержит инструкций для несанкционированного доступа, закрепления, обхода защит или эксфильтрации.