Публичные контейнерные образы: доверяй только digest

«Образ из публичного registry — внешний исполняемый артефакт, а не готовый к запуску пакет. Официальный namespace, знакомый тег и чистый CVE-отчёт не подтверждают происхождение и безопасность. Надёжная проверка связывает один digest с издателем, сборкой, платформой, SBOM, слоями и фактическими правами контейнера — а затем непрерывно пересматривает это решение.»

Где скрывается риск
Публикацию могут подменить через похожий namespace, захваченный CI/CD или украденные credentials издателя. Корректная подпись тоже не доказывает безвредность: скомпрометированный доверенный workflow способен подписать вредоносную сборку.
Тег `latest` или `1.2` изменяем и завтра может указывать на другой объект. Digest фиксирует конкретный манифест, но не делает его безопасным. Для multi-platform образа учитывайте digest индекса и манифест каждой разрешённой платформы: проверка `linux/amd64` ничего не говорит о `linux/arm64`.
Зафиксируйте объект и происхождение
Запишите полный `registry/repository`, время разрешения тега, digest индекса, целевую платформу и digest её манифеста. После допуска deployment должен ссылаться именно на проверенный digest: совпадение тега не переносит одобрение на новый объект.
Проверьте подпись Cosign с явно заданными ожидаемыми OIDC issuer и certificate identity. Слишком широкое регулярное выражение для identity обесценивает контроль. Затем отдельно проверьте provenance attestation: subject digest, исходный repository и commit, builder, workflow, ref и параметры сборки.
SBOM показывает заявленный состав, provenance — как и из чего создан артефакт. Ни один из этих документов сам по себе не доказывает отсутствие вредоносного поведения.
Проверьте состав, слои и конфигурацию
Постройте независимую SBOM для каждой разрешённой платформы, например с помощью Syft в CycloneDX JSON или SPDX JSON. Сравните её с SBOM издателя по пакетам, версиям, purl и лицензиям. Расхождения должны быть объяснены: статически связанные, переименованные и нестандартно установленные компоненты анализаторы нередко пропускают.
Запустите как минимум сканирование уязвимостей и секретов, сохранив версии инструментов, баз и время проверки. Для критичных образов полезен второй сканер. Не принимайте решение только по CVSS: учитывайте наличие исправления, применимость компонента, KEV, EPSS и подписанное VEX-обоснование из доверенного источника.
Отдельно изучите `User`, `Entrypoint`, `Cmd`, `Env`, healthcheck и историю слоёв. Ищите добавленные ключи, токены, загрузчики, package-manager cache, неожиданные setuid-файлы и попытки скрыть артефакты удалением в следующем слое.
Изоляция, допуск и повторная проверка
Если нужен динамический анализ, запускайте штатный startup в одноразовой VM без production-секретов, Docker socket, SSH-agent, внутренних сетей и metadata service. Ограничьте исходящий трафик, CPU, память, процессы и диск; журналируйте DNS, соединения, процессы и изменения файлов. Неожиданные назначения, persistence или privilege escalation должны блокировать допуск.
В runtime применяйте non-root, `allowPrivilegeEscalation: false`, read-only root filesystem, seccomp `RuntimeDefault` и удаление capabilities с точечным возвратом необходимых. Запрещайте privileged mode, host namespaces, неутверждённые `hostPath` и управляющие сокеты.
Повторяйте проверку при изменении digest, появлении новых данных об уязвимостях, отзыве подписи или изменении политики. Храните решение вместе с digest, платформой, результатами сканирования и сроком действия допуска.
Что почитать и попробовать
• Syft
— Строит независимую SBOM образа; задавайте CycloneDX JSON или SPDX JSON явно и проверяйте каждую разрешённую платформу.
• Trivy
— Ищет известные уязвимости и секреты; фиксируйте версии инструмента и баз, время проверки и применённые исключения.
• Cosign
— Проверяет подписи и attestations; закрепляйте ожидаемые OIDC issuer, identity издателя и digest проверяемого образа.
Я в соцсетях
TG · TikTok · Сетка · MAX