Доверенные контейнерные образы для Kubernetes: зачем нужны Axiom Trusted Images

Контейнеры стали языком cloud-native разработки: через них приложения быстрее проходят путь от кода до эксплуатации, проще масштабируются и одинаково запускаются в разных средах. Но чем активнее компании переходят на Kubernetes и микросервисную архитектуру, тем заметнее становится вопрос доверия к тому, что именно запускается внутри контейнера.

На практике базовый образ часто воспринимается как техническая деталь Dockerfile. Команда выбирает готовый образ, добавляет приложение и передаёт его дальше по pipeline. Но именно этот базовый слой определяет, какие системные библиотеки, runtime-компоненты и вспомогательные пакеты попадут в production вместе с приложением.

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

Так сформировался подход hardened images — доверенных контейнерных образов, которые изначально проектируются для безопасной промышленной эксплуатации. Их задача — сделать базовый слой контейнера не «чёрным ящиком», а управляемым и проверяемым элементом cloud-native инфраструктуры.

Почему тема контейнерной безопасности стала бизнес-задачей

Контейнерная безопасность уже вышла за пределы технической гигиены. В российских компаниях проверки безопасности постепенно встраиваются в DevOps-процессы: по данным State of DevOps Russia 2025, 59,9% респондентов подключают средства ИБ к CI/CD, 46,8% используют сканеры уязвимостей в контейнерных образах, а 35,6% — анализаторы конфигураций Kubernetes. При этом 26,8% участников признают, что результаты security-проверок им непонятны. Это важный сигнал: рынок уже сканирует контейнеры, но ещё не всегда умеет быстро превращать результаты сканирования в понятные решения для релиза.

Международная аналитика показывает масштаб проблемы. В отчёте Sysdig 2023 указано, что 87% контейнерных образов содержали уязвимости высокого или критического уровня. Chainguard в исследовании State of Hardened Container Images отмечает, что в анализируемых образах Red Hat в среднем было около 200 CVE, а в 50 наиболее скачиваемых образах Iron Bank — около 110 CVE. Эти цифры не означают, что каждая уязвимость эксплуатируема в конкретном сервисе, но показывают уровень шума, с которым сталкиваются ИБ и DevOps-команды.

Для бизнеса это означает задержки релизов, рост затрат на разбор CVE, сложность аудита и зависимость от качества внешних базовых образов. Поэтому всё чаще вопрос ставится не только как «чем сканировать контейнеры», а  «как уменьшить количество уязвимостей и неопределённости ещё на уровне базового образа».

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

Что такое доверенные контейнерные образы

Доверенный контейнерный образ, или hardened image, — это не просто Docker-образ из реестра. Это проверяемый артефакт с понятным происхождением, фиксированным составом и управляемым жизненным циклом.

Почему обычные контейнерные образы становятся проблемой

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

Главная сложность — унаследованные уязвимости. Команда может написать безопасное приложение, но получить десятки CVE из базового слоя: системных библиотек, пакетов дистрибутива, утилит или старых зависимостей. Сканер покажет проблему, а ИБ и DevOps должны будут понять, относится ли она к реальному риску, кто отвечает за исправление и можно ли выпускать релиз.

Отдельный риск — лишние инструменты внутри production-образа: shell, package manager, отладочные утилиты и запуск от root. В случае компрометации приложения такие компоненты дают атакующему больше возможностей внутри контейнера и усложняют ограничение последствий.

SBOM, подпись и происхождение: что подтверждает доверие

SBOM, или Software Bill of Materials, — это перечень компонентов программного артефакта. Для контейнерного образа SBOM показывает, какие пакеты, библиотеки и зависимости входят в состав базового слоя и среды исполнения. На практике чаще используются форматы CycloneDX и SPDX; SPDX является международным стандартом ISO/IEC 5962:2021, а CycloneDX стандартизирован как ECMA-424.

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

Но одного перечня компонентов недостаточно. В защищённой цепочке поставки важно доказать, что образ не был подменён между сборкой, реестром и Kubernetes. Для этого используются цифровая подпись, проверка происхождения, воспроизводимые сборки, доверенные реестры и политики допуска в Kubernetes. Docker в документации по hardened images также относит к core concepts signed attestations, immutable digests, SLSA и VEX.

Axiom Trusted Images: доверенные образы для cloud-native разработки

Axiom Trusted Images появились как развитие продуктовой экосистемы Axiom JDK. Исторически Axiom JDK решает задачи безопасной эксплуатации Java-приложений, но в cloud-native архитектуре защищать только Java-слой уже недостаточно.

Современное приложение собирается из разных технологических компонентов: Nginx, Node.js, Go, C, C++, специализированных runtime-сред, серверов приложений и контейнерной инфраструктуры. Каждый из этих компонентов поставляется в контейнере и становится частью production-контура. Поэтому безопасность нужно обеспечивать не только на уровне приложения или Java runtime, а на уровне всего базового контейнерного слоя.

Axiom Trusted Images дают командам доверенные защищённые образы с минимальным и проверяемым составом, SBOM, цифровой подписью и регулярным устранением уязвимостей. Это позволяет применять единый подход к безопасности контейнеров независимо от языка разработки, runtime-среды и типа сервиса.

Образы строятся вокруг принципа минимальной и проверяемой среды исполнения. В образ включается только то, что нужно для запуска соответствующей технологии: Nginx, Python, Node.js, Go, C, C++ на основе GCC..

Для Java-сценариев в экосистеме Axiom JDK предусмотрен отдельный продукт — Axiom Runtime Container Pro. Он закрывает задачу безопасного запуска Java-приложений в контейнерной среде. Axiom Trusted Images при этом расширяют подход на другие технологии и позволяют выстроить доверенный базовый слой для всего cloud-native стека.

Основа образов — Axiom Linux, лёгкий дистрибутив, оптимизированный для контейнерных сценариев. Он используется как компактный и производительный базовый слой, на котором собираются защищённые образы для разных технологических стеков.

Ключевые свойства Axiom Trusted Images:

• минимальный фиксированный состав;
• отсутствие лишних пакетов в промышленном образе;
• снижение поверхности атаки;
• варианты поставки под разные сценарии: shell, distroless, rootless;
• прозрачный состав компонентов через SBOM;
• цифровая подпись образов;
• регулярный мониторинг уязвимостей;
• устранение критических уязвимостей в рамках SLA;
• поддержка x86_64 и ARM64;
• развёртывание на российских Linux-дистрибутивах и Kubernetes-платформах.

Интеграция с Kubernetes и DevSecOps

Axiom Trusted Images можно использовать как замену стандартных базовых образов в Dockerfile. Обычно внедрение начинается с замены ссылки на базовый образ, а затем расширяется до более строгих проверок в CI/CD и Kubernetes.

Типовой путь выглядит так: 

• выбрать доверенный образ для нужной технологии, 
• обновить Dockerfile или шаблон сборки, 
• зафиксировать тег или digest, 
• выполнить сканирование, 
• сохранить SBOM,
• проверить подпись, 
• опубликовать образ в контролируемый реестр
• добавить политики допуска в Kubernetes.

Такие политики могут запрещать запуск от root, привилегированные контейнеры и тег latest; ограничивать список разрешённых реестров; проверять подпись образа и соответствие внутренним требованиям ИБ. Обычно для этого применяются Kyverno, OPA Gatekeeper или другие инструменты policy-as-code.

Обычные образы и Axiom Trusted Images: сравнение

Соответствие требованиям ИБ и регуляторов

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

В международной практике доверенные контейнерные образы рассматриваются как часть подхода к защите cloud-native инфраструктуры и цепочки поставки ПО. Они помогают выполнять требования и рекомендации NIST SP 800-190, CIS Benchmarks и ISO 27001 в части контроля состава образов, управления уязвимостями, проверки происхождения компонентов и безопасной эксплуатации контейнеров.

В российской практике эта логика также закрепляется через требования к безопасной разработке ПО. ГОСТ Р 56939-2024 предусматривает применение инструментов композиционного анализа для контроля заимствованных компонентов, их версий, источников и связанных с ними уязвимостей. Для контейнерных образов это напрямую связано с SBOM: перечнем компонентов, который позволяет подтвердить состав базового слоя и упростить подготовку к аудиту.

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

Почему это важно для бизнеса

Контейнеры уже стали основой современной разработки: через них запускаются клиентские сервисы, API, внутренние платформы, интеграционные компоненты и критичные бизнес-системы. Но чем больше контейнеров в production, тем важнее управлять не только приложением, но и базовым слоем, на котором оно работает.

Axiom Trusted Images помогают бизнесу снизить риски контейнерной эксплуатации: вместо разрозненных базовых образов из публичных источников компания получает доверенные образы с понятным составом, SBOM, цифровой подписью и регулярным устранением уязвимостей.

• меньше уязвимостей и шума в отчётах сканеров;
• быстрее прохождение проверок ИБ и аудита;
• меньше задержек при выпуске новых сервисов;
• единый стандарт базовых образов для разных команд;
• ниже затраты на ручное сопровождение контейнеров;
• проще миграция приложений в Kubernetes;
• выше предсказуемость эксплуатации критичных сервисов.

Главный эффект — базовый контейнерный слой перестаёт быть технической зоной неопределённости и становится управляемым элементом безопасной cloud-native разработки.

Где применять Axiom Trusted Images

• production-кластеры Kubernetes;
• банковские и финтех-системы;
• государственные информационные системы;
• платформенные команды, обслуживающие несколько продуктовых команд;
• контуры с повышенными требованиями ИБ и аудита;
• сервисы на Nginx, Node.js, Go, C/C++, и других runtime-компонентах.

Практический чек-лист внедрения

1. Инвентаризировать текущие базовые образы.
2. Проверить количество CVE и понять, какие уязвимости приходят из базового слоя.
3. Выбрать доверенный образ для нужной технологии.
4. Обновить Dockerfile или шаблон сборки.
5. Настроить сканирование уязвимостей в CI/CD.
6. Сохранять SBOM вместе с артефактами выпуска.
7. Проверять подпись образа перед публикацией и запуском.
8. Добавить Kubernetes-политики для запрета небезопасных конфигураций.
9. Зафиксировать процесс обновления базовых образов.

Частые вопросы

Можно ли устанавливать дополнительные пакеты в Axiom Trusted Images?

В промышленном сценарии не рекомендуется доустанавливать пакеты в готовый образ: это нарушает принцип фиксированного и проверяемого состава. Если приложению нужны дополнительные компоненты, их следует добавлять контролируемо — через пересборку образа, повторное сканирование и обновление SBOM. В distroless-образах доустановка пакетов, как правило, невозможна: в них отсутствуют shell и package manager.

Совместимы ли такие образы с существующим CI/CD?

Да. Их можно использовать как полностью совместимую замену стандартных базовых образов, а затем добавить дополнительные проверки: сканирование CVE, сохранение SBOM и проверку подписи.

Подходят ли Axiom Trusted Images для Kubernetes?

Да. Образы можно использовать в Kubernetes как обычные OCI-образы и связывать с политиками допуска, проверкой подписи, запретом root-прав и контролем разрешённых реестров.

Чем доверенные образы отличаются от обычных минимальных образов?

Минимальный размер — только один из факторов. Доверенный образ также должен иметь понятное происхождение, прозрачный состав, регулярное обновление, сканирование уязвимостей, SBOM и механизм проверки целостности.

Вывод

Безопасность контейнеров начинается не в Kubernetes, а раньше — на уровне базового образа и цепочки поставки ПО. Если образ содержит лишние компоненты, не имеет SBOM, не подписан и не обновляется по понятному процессу, Kubernetes-политики смогут компенсировать только часть рисков.

Axiom Trusted Images дают более управляемую основу для промышленной эксплуатации контейнеров: минимальный состав, снижение поверхности атаки, прозрачность компонентов, цифровую подпись и сопровождение уязвимостей. Для бизнеса это способ снизить операционную нагрузку, ускорить проверки ИБ и сделать контейнерную платформу более предсказуемой.