docker • 12 минут

Европейский акт о киберустойчивости и что это значит для команд, работающих с контейнерами

Европейский акт о киберустойчивости (CRA) вводит единые правила кибербезопасности для всех продуктов с цифровыми элементами, продаваемых на территории ЕС. Для команд, которые создают и распространяют контейнерные образы, это означает, что ранее добровольные практики — формирование списка компонентов (SBOM), мониторинг уязвимостей и укрепление образов — становятся обязательными требованиями закона.

Кто подпадает под действие CRA

Регулирование охватывает любое аппаратное или программное изделие, включая его удалённые компоненты, если они необходимы для основной функции продукта. Контейнерные образы, распространяемые коммерчески в ЕС, считаются продуктами с цифровыми элементами. Следовательно, организации, которые публикуют образы в публичных или приватных реестрах и получают за это вознаграждение (платная поддержка, managed services, коммерческий реестр), попадают в категорию производителей и должны выполнять все обязательства CRA.

Основные требования регулирования

CRA делит обязательства на две группы: основные кибербезопасные свойства продукта и порядок обработки уязвимостей на всём жизненном цикле.

Безопасность по дизайну

Образ должен быть собран с минимальной поверхностью атаки: использовать только необходимые пакеты, отключать ненужные оболочки и менеджеры пакетов, задавать безопасные значения по умолчанию и обеспечивать возможность безопасного обновления. Для контейнеров это обычно означает:

использовать минимальные базовые образы (например, distroless или alpine без лишних утилит);
удалять шеллы (bash, sh) и пакетные менеджеры (apt, yum) из финального слоя, если они не нужны во время выполнения;
настраивать непривилегированного пользователя (USER) и ограничивать права файловой системы;
обеспечивать проверку целостности через криптографические подписи и provenance‑аттестации.

SBOM и прозрачность состава

Производители должны включать машинночитаемый список компонентов в техническую документацию каждого продукта. Формат не жёстко предписан, но на практике используют SPDX или CycloneDX. Для контейнеров удобно генерировать SBOM во время сборки, чтобы он отражал точное содержимое образа.

Обработка уязвимостей и отчётность

Необходимо установить процесс выявления, документирования и устранения уязвимостей в течение заявленного периода поддержки. С 11 сентября 2026 года вступает в силу обязанность сообщать об активно эксплуатируемых уязвимостях и серьёзных инцидентах в национальные CSIRT и ENISA. Сроки уведомления:

24 часа — предварительное уведомление;
72 часа — полное уведомление с техническими деталями;
14 дней — окончательный отчёт после выпуска исправления (для активно эксплуатируемых уязвимостей);
1 месяц — окончательный отчёт для серьёзных инцидентов.

При подготовке отчётов следует ограничиваться только технической информацией, необходимой для оценки риска, и обрабатывать любые персональные данные в соответствии с GDPR.

Оценка соответствия и маркировка CE

Перед выходом на рынок производитель должен пройти процедуру оценки соответствия. В зависимости от уровня риска продукт попадает в один из трёх классов. Большинство коммерческих контейнерных рантаймов относятся к важному классу II, что требует привлечения независимой сторонней организации для аудита. Успешная оценка даёт право нанесения маркировки CE, подтверждающей соответствие CRA.

Практические шаги для контейнерных команд

Чтобы подготовиться к срокам действия CRA, рекомендуется внедрить следующие меры в существующие процессы CI/CD и эксплуатации.

Генерация и проверка SBOM

Сборка образа с включённым формированием SBOM может выполняться средствами BuildKit или отдельными сканерами. Пример команды с использованием syft (инструмент, поддерживающий SPDX и CycloneDX):

# Сборка образа (предполагается, что Dockerfile находится в текущей директории)
docker build -t myapp:latest .

# Генерация SBOM в формате SPDX JSON
syft myapp:latest -o spdx-json > sbom.spdx.json

# Проверка, что файл содержит необходимые поля
jq '.packages | length' sbom.spdx.json

Полученный SBOM следует сохранять в артефактах сборки и прикреплять к образу в виде attestation (например, через cosign или notation). При необходимости его можно предоставить регулятору по запросу.

Мониторинг уязвимостей

Для выполнения требований по своевременному выявлению и устранению уязвимостей нужен постоянный сканер образов. Популярные открытые решения — Trivy, Grype или коммерческий Docker Scout. Пример регулярного сканирования в CI:

# Сканирование образа и вывод в формате JSON для дальнейшей обработки
trivy image --format json --output trivy-report.json myapp:latest

# Фильтрация только критических уязвимостей
jq '.Results[].Vulnerabilities[] | select(.Severity=="CRITICAL\))' trivy-report.json

Полученные данные используются для создания билетов в системе отслеживания задач и инициирования процесса патч‑менеджмента.

Укрепление образов (hardening)

Следует автоматизировать проверку соответствия образу требованиям минимальной поверхности атаки. Можно использовать политики в Conftest или OPA Gatekeeper для проверки наличия запрещённых пакетов, пользователя root и открытых портов. Пример простого проверочного скрипта на bash:

#!/usr/bin/env bash
IMAGE="myapp:latest"

# Проверяем, что образ не содержит шелл bash
if docker run --rm $IMAGE bash -c "which bash" 2>/dev/null; then
    echo "ОШИБКА: обнаружен bash в образе"
    exit 1
fi

# Проверяем, что процесс запускается от непривилегированного пользователя
USER=$(docker run --rm $IMAGE ps -o user= -p 1 2>/dev/null | head -n1)
if [[ "$USER" == "root" ]]; then
    echo "ОШИБКА: образ запускается от root"
    exit 1
fi

echo "Образ прошёл базовые проверки hardening"

Данный скрипт можно добавить в этап проверки перед публикацией образа в реестр.

Определение и публикация периода поддержки

Производитель должен чётко указать, как долго он будет предоставлять исправления для каждого тега образа. Эта информация обычно помещается в метки образа или в сопроводительную документацию. Пример добавления метки при сборке:

docker build \
    --label "com.example.support-period=24m" \
    -t myapp:2024.10 .

Потребители смогут проверить наличие и актуальность поддержки через стандартные инструменты работы с метаданными образов (docker inspect или crane).

Выводы

EU Cyber Resilience Act превращает многие рекомендации по безопасности контейнеров в обязательные нормы. Для успешного соответствия достаточно внедрить в пайплайн:

автоматическую генерацию SBOM во время сборки;
регулярное сканирование образов на уязвимости и быстрый выпуск исправлений;
сборку минимальных, укреплённых образов без лишних компонентов;
подтверждение целостности через подписи и provenance;
чёткое определение и публикацию периода поддержки каждого тега.

Эти шаги не только помогут избежать штрафов и возможного wycofания продукта с рынка ЕС, но и повысят общий уровень надёжности и доверия к вашим контейнерным решениям.