Генерация SBOM для Docker-образов с помощью `docker sbom`

Быстрые ссылки

• The “docker sbom” Command

• Customizing Output

• Use Cases

• Summary

Что такое SBOM в двух словах

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

Команда docker sbom

Команда docker sbom вошла в состав Docker Desktop, начиная с версии 4.7.0. На Linux можно добавить поддержку в Docker Engine через плагин docker-sbom, который доступен на GitHub.

Установка плагина (однострочный скрипт):

$ curl -sSfL https://raw.githubusercontent.com/docker/sbom-cli-plugin/main/install.sh | sh -s --

Проверьте установку командами:

$ docker sbom

Вывод подскажет синтаксис:

Usage: docker sbom [OPTIONS] COMMAND

View the packaged-based Software Bill Of Materials (SBOM) for an image.

...

Чтобы сгенерировать SBOM для образа, передайте его тег:

$ docker sbom nginx:latest

Пример вывода (Syft v0.43.0):

✔ Pulled image

✔ Loaded image

✔ Parsed image

✔ Cataloged packages [143 packages]

NAME VERSION TYPE

adduser 3.118 deb

apt 2.2.4 deb

base-files 11.1+deb11u3 deb

base-passwd 3.5.51 deb

bash 5.1-2+b3 deb

bsdutils 1:2.36.1-8+deb11u1 deb

...

Если образ отсутствует локально, CLI подтянет его и просканирует содержимое. Под капотом используется Syft — популярный генератор SBOM. Docker показывает версию Syft при каждом запуске и вывод совпадает с тем, что дала бы отдельная установка Syft.

Syft умеет распознавать пакеты ОС и зависимости языков программирования. В выводе рядом с именем пакета указаны его тип и версия, что упрощает аудит образов и помогает оценивать, затронут ли вы уязвимостью.

Настройка формата и сохранения вывода

По умолчанию вывод читается человеком в виде таблицы — удобно для размещения рядом с образом или в документации.

• Чтобы убрать строки с версией Syft и индикатором прогресса, используйте флаг --quiet.
• Чтобы записать результат в файл вместо терминала, используйте --output.

Пример сохранения:

$ docker sbom --output sbom.txt --quiet nginx:latest

Для машиночитаемого потребления доступны форматы через флаг --format. Варианты:

• text — альтернативный человекочитаемый вид с построчным представлением.
• syft-json — собственный JSON-формат Syft.
• cyclonedx-xml / cyclonedx-json — совместимый с CycloneDX (стандарт, поддерживаемый сообществом); удобен для интеграции с инструментами цепочки поставок.
• github-0-json — формат, совместимый с GitHub.
• spdx-tag-value / spdx-json — совместимость со стандартом SPDX (Linux Foundation).

Пример вывода в текстовом формате:

$ docker sbom --format text --quiet nginx:latest

[Image]

Layer: 0

Digest: sha256:9c1b6dd6c1e6be9fdd2b1987783824670d3b0dd7ae8ad6f57dc3cea5739ac71e

Size: 80400891

MediaType: application/vnd.docker.image.rootfs.diff.tar.gzip

…

[adduser]

Version: 3.118

Type: deb

Found by: dpkgdb-cataloger

[apt]

Version: 2.2.4

Type: deb

Found by: dpkgdb-cataloger

Раздел в квадратных скобках “Image” перечисляет слои образа и их метаданные. Дальше идут блоки с обнаруженными пакетами, где указаны тип, версия и источник обнаружения.

Как исключать пути из сканирования

Иногда нужно игнорировать системные каталоги и индексировать только директории с приложением. Для этого передаётся glob-выражение в --exclude.

$ docker sbom --exclude /var nginx:latest

Сканирование образов для других архитектур

Чтобы просканировать образ, собранный для другой архитектуры (например arm64), используйте --platform:

$ docker sbom --platform arm64 nginx:latest

Это удобно для индексации многоплатформенных образов без переключения оборудования.

Примеры использования SBOM

• Аудит безопасности: быстро сопоставить список пакетов с базами уязвимостей и понять, какие версии затронуты.
• Политики соответствия: проверять, что в образах нет запрещённых библиотек или лицензий.
• Оценка покрытия зависимостей: найти избыточные или неиспользуемые пакеты и сократить поверхность атаки.
• Интеграция в CI/CD: генерировать SBOM при сборке и размещать его рядом с образом в реестре.

Пример передачи в Grype для поиска CVE:

$ docker sbom --format syft-json nginx:latest | grype

Когда docker sbom работает не так хорошо (ограничения и случаи провала)

• Многоуровневые и сильно модифицированные образы: если файлы собраны нестандартным способом, часть библиотек может не обнаружиться.
• Шифрованные или упакованные артефакты: упакованный или сжимаемый бинарник может скрыть внутренние зависимости.
• Исключённые пути: если вы используете --exclude слишком широко, можно пропустить критичные пакеты.
• Образы с зависимостями, установленными нестандартным менеджером: редкие или самописные менеджеры пакетов могут не распознаваться.

Важно понимать, что docker sbom сейчас выполняет активное сканирование файловой системы образа. В будущей модели SBOM может создаваться во время сборки и храниться вместе с образом, что снизит вероятность ошибок обнаружения.

Альтернативные подходы

• Syft отдельно: даёт богатые опции и обновления независимо от Docker; можно комбинировать с другими инструментами.
• Запуск специализированных сканеров уязвимостей (Grype, Trivy, Clair) прямо на SBOM или на образе.
• Интеграция SBOM в процесс сборки (например, в Dockerfile или в инструмент сборки образа), чтобы иметь гарантированную прослеживаемость.

Методика внедрения SBOM в CI (мини-методология)

1. На этапе сборки образа запускать docker sbom --format syft-json и сохранять вывод как артефакт сборки.
2. Проверять SBOM на соответствие политике безопасности (например, запрещённые лицензии или пакеты).
3. Прокидывать SBOM в сканер уязвимостей (Grype) и генерировать отчёт.
4. На этапе деплоя публиковать SBOM вместе с образом в реестр или хранилище артефактов.
5. Вести версионирование SBOM синхронно с версией образа.

Пример фрагмента CI (bash):

# Сборка образа
docker build -t myapp:${CI_COMMIT_SHA} .

# Генерация SBOM в формате Syft JSON
docker sbom --format syft-json myapp:${CI_COMMIT_SHA} > sbom-${CI_COMMIT_SHA}.json

# Сканирование SBOM утилитой Grype
cat sbom-${CI_COMMIT_SHA}.json | grype -

# Загрузка SBOM как артефакта сборки
# (пример для GitLab/GitHub Actions — сохранить файл в артефактах)

Ролевая чек-лист: кто что делает

• Разработчик:

  • Генерировать SBOM локально при релизе.
  • Минимизировать зависимости в приложении.

• DevOps/Build-инженер:

  • Интегрировать генерацию SBOM в CI.
  • Хранить SBOM рядом с образом в реестре.

• Инженер по безопасности:

  • Проводить автоматический анализ SBOM на CVE.
  • Устанавливать правила допуска/блокировки пакетов.

• QA:

  • Проверять, чтобы сборки сопровождались актуальной SBOM.

Критерии приёмки для автоматизации SBOM

• Каждый CI-билд образа должен сохранять SBOM в машиночитаемом формате (syft-json/cyclonedx).
• При наличии критичных CVE билд помечается как failed или создаётся таск в трекере.
• SBOM доступен в реестре или как артефакт сборки в течение жизненного цикла релиза.

Когда интеграция SBOM полезна, а когда нет

Полезно:

• в организациях с регуляторными требованиями;
• при использовании большого числа внешних библиотек;
• когда важно быстро реагировать на CVE.

Менее полезно:

• для временных, одноразовых контейнеров без внешних зависимостей;
• если инфраструктура не позволяет сохранить или использовать SBOM (напр., строгое оффлайн-среда без процессов доставки артефактов).

Глоссарий в одну строку

• SBOM — список компонентов программного артефакта.
• Syft — инструмент для генерации SBOM из образов и файловых систем.
• Grype — сканер уязвимостей, работающий с SBOM и образами.
• CycloneDX / SPDX — стандарты форматов SBOM.

Практические рекомендации и хинты

• Регулярно обновляйте Syft/плагин, чтобы распознавались новые форматы пакетов.
• Используйте минимальные базовые образы (alpine, distroless), чтобы уменьшить количество пакетов и поверхность атаки.
• Публикуйте SBOM вместе с образом в реестре, чтобы сторонние пользователи могли оценить риск.
• Автоматизируйте проверку SBOM в CI и интегрируйте с баг-трекером при обнаружении критичных проблем.

:::important Текущее поведение docker sbom — это активное сканирование файловой системы образа. В будущем ожидается модель, где SBOM создаётся и прикладывается на этапе сборки, что обеспечит более детерминированный и полный результат. :::

Сравнение подходов (кратко)

• docker sbom (интегрирован в Docker): прост в использовании, не требует отдельной установки на Desktop; использует Syft под капотом.
• Syft standalone: даёт расширенные опции и быстрее обновляется независимо от Docker.
• Интеграция в build pipeline: даёт гарантию, что SBOM создаётся одновременно со сборкой и хранится как часть артефакта.

Резюме

Команда docker sbom предоставляет удобную точку входа для генерации SBOM прямо из Docker CLI. Это снижает барьер для внедрения SBOM в процессы разработки и помогает быстрее находить уязвимости и избыточные зависимости. Для надёжных процессов рекомендуется интегрировать генерацию SBOM в CI, сохранять SBOM вместе с образом и автоматически запускать сканеры уязвимостей.

Короткая практическая рекомендация: обновите Docker Desktop до v4.7.0 или установите плагин docker-sbom на Linux, генерируйте SBOM при каждой сборке и прокидывайте его в сканер уязвимостей (например Grype).

Дополнительные ресурсы и ссылки

• Официальный репозиторий Syft: https://github.com/anchore/syft
• Документация CycloneDX: https://cyclonedx.org
• Форматы SPDX: https://spdx.org