«Образ из публичного 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