syft: состав образа Docker, SBOM и проверка лицензий
Trivy отвечает на вопрос «какие уязвимости есть в образе сейчас». Отдельная, более базовая задача — просто знать точный состав образа: какие пакеты, каких версий, с какими лицензиями. Это и называется SBOM (software bill of materials, перечень состава ПО). syft строит такой перечень за секунды и в стандартном формате, которым можно обмениваться с партнёрами или прикладывать к релизу.
Статья опирается на логику направления «Управление ИТ-активами» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Проверка выполнена syft 1.54.1 против официального образа alpine:3.20, после неё образы удалены.
Что должно получиться
| Уровень | Что это значит на практике |
|---|---|
| 1. Начальный | Для каждого используемого образа есть точный и актуальный список входящих в него пакетов, а не предположение «там же просто Alpine» |
Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.
Запуск
docker run --rm anchore/syft:latest ИМЯ_ОБРАЗА -o tableНа образе alpine:3.20 команда за несколько секунд вывела таблицу из 14 пакетов с именем, версией и типом (apk — формат пакетов Alpine). Для своего образа, собранного на базе более насыщенного дистрибутива (Debian, Ubuntu) или с добавленными зависимостями приложения (Python, Node.js), список будет на порядок длиннее — именно в таких образах SBOM особенно ценен, потому что никто не помнит точный состав наизусть.
Форматы вывода
syft ИМЯ_ОБРАЗА -o json # полный разбор для скриптовой обработки
syft ИМЯ_ОБРАЗА -o cyclonedx-json # стандартный формат CycloneDX для обмена с партнёрами и инструментами
syft ИМЯ_ОБРАЗА -o spdx-json # альтернативный стандарт SPDXCycloneDX и SPDX — открытые стандарты, которые понимают многие другие инструменты (сканеры уязвимостей, системы комплаенса), поэтому SBOM в одном из этих форматов можно передать дальше по цепочке, а не только смотреть глазами.
Результат проверки
В JSON-выводе для образа alpine:3.20 каждый пакет сопровождается не только именем и версией, но и сведениями о лицензии и точным путём внутри образа, где пакет был обнаружен. Например, для пакета alpine-baselayout:
{
"name": "alpine-baselayout",
"version": "3.6.5-r0",
"licenses": [{"value": "GPL-2.0-only", "type": "declared"}]
}Это позволяет автоматически проверять, не попал ли в образ пакет с лицензией, запрещённой корпоративной политикой (например, строгие копилефт-лицензии в продукте, который распространяется клиентам) — без такого списка вопрос о лицензионной чистоте образа решается только вручную.
Что делать с результатом
- Прикладывайте SBOM к каждому релизу рядом с образом — при вопросе «а что у вас там внутри» (от клиента, аудитора, регулятора) ответ готов за секунды, а не требует нового сканирования.
- Сравнивайте SBOM между версиями образа: разница в списке пакетов — наглядный способ увидеть, что реально изменилось при обновлении базового образа.
- Передавайте SBOM в сканер уязвимостей отдельно от самого образа: если партнёр не может запустить сканирование вашего образа (нет доступа), SBOM даёт ему достаточно данных, чтобы сверить состав с базами уязвимостей самостоятельно.
- Автоматически проверяйте лицензии в конвейере сборки, если ваш продукт распространяется за пределы компании.
Порядок внедрения
- Добавьте генерацию SBOM как шаг конвейера сборки, сразу после сборки образа.
- Сохраняйте SBOM вместе с образом в том же хранилище артефактов, с привязкой к версии.
- Подключите проверку лицензий для продуктов, распространяемых за пределы компании.
- Используйте SBOM как источник данных для сканирования уязвимостей и для учёта установленного ПО — обе задачи логически связаны с составом образа.
Диагностика
| Симптом | Причина и что делать |
|---|---|
| В списке нет зависимостей приложения (например, пакетов Python) | syft анализирует то, что видит в файловой системе образа — виртуальное окружение или `site-packages` должны быть реально установлены в слоях образа, а не монтироваться снаружи при запуске |
| Лицензия не определена для части пакетов | Пакет не декларирует лицензию в стандартном месте, которое проверяет syft. Для таких пакетов проверяйте лицензию вручную по документации проекта |
| SBOM двух версий образа выглядит одинаковым, хотя код менялся | Изменился только код приложения, а не состав системных пакетов — SBOM отражает именно пакетный состав, а не ваш код. Для кода нужен отдельный учёт версий из системы контроля версий |
| Нужно сравнить два SBOM автоматически | Используйте утилиты сравнения JSON (jd, jq) по полю списка пакетов, а не читайте вручную построчно |
Где это в модели зрелости
Материал относится к направлению «Управление ИТ-активами» (материалы направления, карта зрелости). Начальный уровень требует точного знания состава используемого ПО: SBOM даёт это знание для образов контейнеров автоматически, без ручной инвентаризации по памяти.
Как проверить
- Для каждого образа, выходящего из конвейера сборки, автоматически формируется SBOM.
- SBOM сохраняется вместе с версией образа, доступен без повторного сканирования.
- Лицензии пакетов проверяются автоматически там, где это требуется условиями распространения продукта.
- SBOM используется как вход для сканирования уязвимостей и учёта ПО, а не существует отдельно и без применения.
Источники
- Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
- Документация syft: github.com/anchore/syft; спецификация CycloneDX: cyclonedx.org.
