NiceOS.Container SBOM + CVE control near-zero known CVE target

Контейнерная сборка НАЙС.ОС для безопасных production-образов

NiceOS.Container — это отдельный облегчённый поток НАЙС.ОС для контейнеров, OCI-образов, Kubernetes, CI/CD и прикладных runtime-слоёв. Его задача — дать современную, минимальную и проверяемую базу, где нет лишней операционной системы внутри контейнера, а каждый образ можно связать с исходниками, RPM-составом, SBOM, результатами сканирования и конкретным immutable digest.
RPM/glibc база частые пересборки SBOM для образов Grype / Trivy scan без systemd в контейнерном runtime
Каталог контейнерных образов Обсудить внедрение
minimal в образ попадает только то, что реально нужно приложению и его runtime-зависимостям
fresh современные версии ПО и быстрый цикл обновлений вместо ожидания долгих backport-окон
signed контроль происхождения артефактов, версий, тегов, digest и состава сборки
scanned SBOM, Grype/Trivy и регламент пересборки при появлении новых CVE-данных
OCI Kubernetes GitOps audit-ready

Что такое NiceOS.Container

Обычная серверная ОС проектируется как универсальная среда: в ней много инструментов администрирования, сервисов, shell-утилит, документации, совместимых библиотек, legacy-компонентов и сценариев для разных ролей. В контейнере такая универсальность часто превращается в балласт: больше пакетов, больше CVE-кандидатов, больше непонятных зависимостей и сложнее аудит.

NiceOS.Container решает другую задачу: собрать узкий, контролируемый и регулярно пересобираемый runtime-слой для контейнеров. Это не «полный сервер внутри контейнера», а минимальная база для запуска конкретного процесса: web-сервера, базы данных, экспортёра, CLI-инструмента, прикладного сервиса или совместимого migration-target образа.

Идеология проста: меньше лишнего, новее исправления, чаще пересборки, прозрачнее состав, быстрее закрытие CVE. Поэтому контейнерная ветка НАЙС.ОС живёт отдельно от универсальной серверной системы и сопровождается как специализированный stream для cloud-native инфраструктуры.

Коротко
  • Отдельная сборка: NiceOS.Container — самостоятельный облегчённый stream, а не просто профиль обычной ОС.
  • Контейнерный runtime: без systemd, без фоновой «серверной ОС», с запуском через entrypoint/foreground-процесс.
  • RPM-controlled provenance: состав образа строится из контролируемых RPM-пакетов и spec-файлов.
  • Supply chain: SBOM, сканирование Grype/Trivy, immutable tags и digest как обязательная часть релиза.

Почему не обычная ОС в контейнере

Контейнер — это не виртуальная машина. Ему не нужен полный набор серверных ролей, init-система, лишние сервисы и инструменты администрирования. Чем больше внутри образа компонентов, тем шире поверхность атаки и тем больше работы для CVE-процесса.

Проблема универсальных баз
  • в образ попадают shell, package manager, документация, debug-утилиты и системные инструменты, которые не нужны приложению;
  • каждый лишний пакет добавляет зависимости, CVE-события и работу по анализу ложных/актуальных уязвимостей;
  • обновления часто завязаны на жизненный цикл большой ОС, а не на скорость закрытия конкретной уязвимости;
  • сложнее доказать, что именно находится внутри образа и почему конкретный компонент там нужен;
  • контейнер начинает вести себя как маленькая VM, а не как воспроизводимый runtime-артефакт.
Подход NiceOS.Container
  • формируем минимальный runtime под задачу образа: только приложение и обязательные библиотеки;
  • удаляем package managers, build tools, кэши, man/info/docs и всё, что не требуется в финальном runtime;
  • пересобираем базовые и прикладные слои часто, чтобы быстрее подтягивать исправления upstream;
  • фиксируем версию образа, ревизию, stream НАЙС.ОС, digest, SBOM и scan-результаты;
  • разделяем build-stage и final runtime: сборка может быть удобной, финальный образ должен быть чистым.

Идеология контейнерной сборки

Новейшее сопровождаемое ПО

Используем актуальные стабильные upstream-релизы и быстро пересобираем пакеты при выходе исправлений. Цель — не «заморозить» runtime на годы, а держать контейнерный слой рядом с текущим безопасным состоянием upstream.

Практически ежедневные пересборки

Базовые и прикладные образы можно пересобирать часто даже без изменения версии приложения: меняются системные библиотеки, CA, tzdata, runtime-зависимости, CVE-метаданные и scan-база.

Near-zero known CVE как процесс

«Near-zero CVE» — это не рекламная гарантия, а операционная модель: минимизация пакетов, быстрые rebuild-циклы, SBOM, сканирование и повторный выпуск образа, когда обнаружена устранимая уязвимость.

Отсутствие лишних пакетов

В финальном runtime не должно быть компиляторов, сборочных систем, package managers, systemd, SSHD, временных файлов, repo metadata и диагностических инструментов, если они не нужны самому workload.

Контроль версий и происхождения

Пакеты проходят через spec-файлы, release-ревизии, теги исходников, immutable image tags, OCI-labels и digest. Это позволяет понять, из чего собран образ и чем он отличается от предыдущего.

SBOM и сканирование

Для релизов формируется состав компонентов, а образы проверяются инструментами Grype и Trivy. Результаты сканирования используются как вход в release-gate и CVE-процесс.

Что мы делаем последовательно

NiceOS.Container строится как повторяемая фабрика образов: от исходников и RPM-пакетов — к минимальному rootfs, OCI-образу, SBOM, сканированию, immutable-тегу и публикации. Это не ручная «сборка Dockerfile на сервере», а контролируемый pipeline с проверяемыми этапами.

Мониторинг upstream, CVE и релизов

Отслеживаем новые версии приложений, системных библиотек, runtime-зависимостей и базы уязвимостей. Для контейнеров важна скорость реакции: исправление должно попадать в новый образ без ожидания большого релиза ОС.

Сборка RPM-пакетов в NiceOS.Container stream

Компоненты собираются как RPM с контролируемыми spec-файлами, зависимостями и changelog. Это даёт управляемую provenance-модель и возможность повторить состав образа.

Формирование минимального container rootfs

В installroot попадают только необходимые runtime-пакеты. Build-only инструменты остаются в сборочном слое и не переходят в финальный образ.

Сборка базовых и прикладных OCI-образов

На базе NiceOS.Container собираются base-слои, compatibility-слои и прикладные образы: NGINX, Redis Open Source, Git, exporters и другие сервисы.

Очистка финального runtime

Удаляются package managers, build tools, кэши, временные файлы, repo metadata, лишние docs/man/info и сервисные компоненты, которые не нужны в production-контейнере.

SBOM, Grype, Trivy и release-gate

Для образа фиксируется состав компонентов, затем выполняется сканирование. Если уязвимость устранима обновлением или пересборкой, образ не должен «лежать месяцами» в старом состоянии.

Публикация immutable tags и digest

Релиз получает предсказуемый тег, ревизию, OCI-labels и digest. В production рекомендуется использовать immutable tag или digest, а не полагаться на плавающий latest.

Повторный цикл пересборки

Даже если приложение не изменилось, образ может быть пересобран ради системных исправлений, обновления CA/tzdata, закрытия CVE или улучшения состава runtime.

Supply chain: контроль состава, версий и уязвимостей

Для контейнерной платформы мало сказать «образ свежий». Нужно показать, что внутри, как он собран, какой digest опубликован, какие проверки прошёл и что изменилось между релизами.

Контроль Что фиксируем Зачем это нужно
RPM provenance пакет, версия, release, spec-файл, changelog, зависимости понять, из каких исходников и правил сборки появился компонент
SBOM перечень компонентов и библиотек в образе быстро сопоставлять состав образа с CVE-базами и внутренним аудитом
Grype / Trivy результаты сканирования образа на известные уязвимости не выпускать образ «вслепую» и отслеживать устранимые CVE
Immutable tags <appVersion>-niceos<stream>-r<revision> однозначно связать runtime с версией приложения, потоком ОС и ревизией образа
Digest sha256 digest опубликованного OCI-образа закрепить ровно тот артефакт, который прошёл проверки
Runtime cleanup отсутствие package managers, build tools, лишних сервисов и кэшей снизить поверхность атаки и количество CVE-кандидатов

Какие образы строятся на базе NiceOS.Container

Базовые runtime-слои

Минимальная glibc/RPM-база для запуска приложений и сборки более специализированных образов. В ней нет цели заменить полноценную серверную ОС — это фундамент для контейнеров.

  • минимальный userspace;
  • контролируемые RPM-зависимости;
  • предсказуемые теги и ревизии;
  • регулярный rebuild под CVE-процесс.
Compatibility-слои

Для миграции популярных контейнерных сценариев нужны не только бинарники, но и привычный runtime contract: пути, env-переменные, UID/GID, entrypoint-поведение, probes и volume-структура.

  • /opt/bitnami и совместимые runtime-пути там, где это нужно для миграции;
  • non-root UID/GID 1001 для совместимых образов;
  • *_FILE handling для секретов;
  • поддержка read-only root filesystem и Kubernetes-паттернов.
Прикладные production-образы

NGINX, Redis Open Source, Git, exporters, WAF/EdgeShield-компоненты и другие образы собираются как отдельные app-репозитории, а не как случайные Dockerfile-форки.

  • отдельный app repository и changelog;
  • release manifest и digest;
  • smoke/regression-тесты;
  • публикация в registry с immutable tags.
Marketplace и Helm-сценарии

На той же базе можно собирать контейнерные продукты для облачных маркетплейсов, Docker Compose, Helm chart, Kubernetes и закрытых корпоративных registry.

  • единая база для Docker/Kubernetes;
  • параметризация через env и secret-файлы;
  • образ + chart + SBOM + scan как единый релиз;
  • готовность к закрытым контурам и внутренним зеркалам.

Политика версий и тегов

Главный принцип: production должен ссылаться на проверяемый и повторяемый артефакт. Поэтому у образа есть версия приложения, stream NiceOS.Container, revision сборки и digest.

1.31.1-niceos13-r1

Immutable tag. Версия приложения + поток NiceOS.Container + ревизия образа. Рекомендуется для production.

sha256:...

Digest. Максимально точная фиксация конкретного OCI-артефакта после публикации и проверки.

latest

Convenience channel. Удобен для знакомства и тестов, но не должен быть единственной ссылкой в production.

Пример эксплуатационной проверки образа

NiceOS.Container ориентирован на проверяемость. Образ можно подтянуть, запустить smoke-test, просканировать и закрепить в deployment по immutable tag или digest.

Запуск и smoke-test
docker pull docker.io/niceos/nginx:1.31.1-niceos13-r1

docker run --rm \
  docker.io/niceos/nginx:1.31.1-niceos13-r1 \
  nginx -v

docker image inspect \
  docker.io/niceos/nginx:1.31.1-niceos13-r1 \
  --format '{{json .RepoDigests}}'
Сканирование
trivy image \
  docker.io/niceos/nginx:1.31.1-niceos13-r1

grype \
  docker.io/niceos/nginx:1.31.1-niceos13-r1

# production-рекомендация:
# закреплять deployment на immutable tag или digest

Часто задаваемые вопросы

Это отдельный облегчённый stream НАЙС.ОС для контейнеров. Он использует RPM/glibc-подход и контролируемые spec-файлы, но не пытается перенести в контейнер всю универсальную серверную ОС. В контейнерный runtime попадает только то, что нужно для запуска конкретного workload.

Можно, и для многих задач это рабочий путь. Но универсальные базы обычно несут больше компонентов, чем нужно конкретному контейнеру. NiceOS.Container решает задачу иначе: минимальный runtime, контролируемый состав, частые пересборки, SBOM, сканирование и собственный CVE-процесс. Это особенно важно там, где контейнерные образы проходят аудит, security gate и регулярное обновление.

Нет. Корректная формулировка — near-zero known CVE target. Это целевое состояние процесса, а не обещание, что внешние базы никогда не найдут новую уязвимость. Новые CVE появляются постоянно, часть записей бывает спорной или неприменимой к конкретному runtime. Задача NiceOS.Container — быстро выявлять, классифицировать, пересобирать и выпускать новый образ, если уязвимость устранима.

Контейнер должен запускать основной процесс в foreground или через понятный entrypoint/supervisor-паттерн. Systemd нужен полноценной ОС или VM, но в минимальном контейнерном runtime он добавляет лишнюю сложность, фоновые сущности и нецелевую модель управления сервисами. Поэтому для NiceOS.Container по умолчанию: без systemd unit, без systemctl, без daemon-reload и без service enable/start внутри образа.

Для многих enterprise-приложений важна привычная glibc-совместимость: бинарники, плагины, драйверы, language runtimes и vendor-инструменты часто тестируются именно с glibc. NiceOS.Container выбирает glibc/RPM-модель как практичный баланс: меньше лишнего, но без потери совместимости с большим числом Linux-приложений.

В production runtime — нет, если он не нужен самому сценарию. Package manager удобен в build-stage, но в финальном образе он обычно увеличивает поверхность атаки и добавляет возможность неконтролируемого изменения состава контейнера. Поэтому финальный runtime очищается от tdnf, dnf, yum, компиляторов, сборочных систем и repo metadata.

Идеальная модель для контейнерной ветки — частые, практически ежедневные пересборки базовых слоёв и быстрый rebuild прикладных образов при появлении исправлений. Реальная частота зависит от конкретного app, CVE-событий, релиза upstream и стадии публикации, но архитектура NiceOS.Container рассчитана именно на быстрый цикл, а не на редкие монолитные релизы.

Да, такая модель предусмотрена: образы, SBOM, scan-отчёты, RPM-репозитории и Helm/OCI-артефакты можно зеркалировать во внутренний registry и внутренние репозитории. Для закрытого контура обычно фиксируют digest, локальные зеркала, регламент обновлений, процедуру повторного сканирования и правила допуска образов в production.

Он стандартизирует базовый слой, на котором живут контейнерные приложения: меньше различий между образами, понятнее CVE-процесс, проще security gate, легче закреплять digest и вести SBOM-аудит. Для CI/CD это означает, что образ становится не случайным результатом Dockerfile, а управляемым релизным артефактом.

Для пилота можно начать с одного-двух образов: например, web-сервер, Redis Open Source, Git, exporter или внутренний сервис. Дальше фиксируются требования: registry, SBOM, CVE-gate, air-gapped контур, Kubernetes/Helm, SLA и регламент обновлений. Связаться можно через форму https://niceos.ru/contact-niceos или по почте support@niceos.ru.
Next step Pilot ready

Начните с пилота: один app, один registry, один CVE-регламент

Лучший способ проверить подход — взять один реальный сервис, собрать его на NiceOS.Container, сформировать SBOM, пройти Grype/Trivy, закрепить digest и сравнить состав образа с текущей базой.

Запросить пилот