SBOM для приложения: какие библиотеки действительно попали на сервер

MAATRIX · 17 октября 2026 · 8 мин чтения

В новостях появляется сообщение об уязвимости библиотеки. Разработчик смотрит основной файл зависимостей и отвечает: «Мы такую не используем». Через час выясняется, что она пришла внутри другого пакета, а ещё одна копия лежит в базовом образе контейнера. Приложение небольшое, список гостей получился длинным.

SBOM — перечень программных компонентов конкретного артефакта. Он помогает понять состав образа, найти затронутые выпуски и сравнить версии. Для первого проекта достаточно получить документ с помощью Syft, привязать его к digest контейнера и проверить найденные компоненты.

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

Исходный код и готовый образ рассказывают разные истории

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

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

Многоэтапная Docker-сборка хорошо показывает разницу. Первый этап содержит компилятор и инструменты, последний — только результат. Если анализировать весь каталог проекта, можно приписать рабочему контейнеру то, чего там нет. Если смотреть только один исполняемый файл без метаданных, часть состава может остаться неизвестной.

Укажите в отчёте границы: образ, архитектура, версия Syft, дата и способ сканирования. Честное описание области анализа ценнее внушительного JSON без понятного происхождения.

Где выполнять проверку

Удобно создавать SBOM в CI после сборки и до выпуска. Тогда каждому артефакту соответствует собственный перечень. Дополнительно можно проверять уже опубликованный образ, чтобы убедиться в совпадении digest.

Для небольшого отдельного стенда подойдёт MAATRIX Uab Start с 2 vCPU и 4 GB памяти. Для крупных образов, нескольких параллельных проверок и хранения истории ресурсов потребуется больше. Размер выбирайте по времени сканирования, памяти и объёму скачиваемых слоёв.

Используйте поддерживаемую Ubuntu или Debian и устанавливайте инструменты из официальных выпусков с проверкой происхождения. Сканирующему процессу достаточно доступа к выбранному образу. Не выдавайте ему полный доступ к рабочей базе и секретам приложения.

Если проверяете образы через Docker socket, помните о высоких полномочиях такого доступа. Для отдельной задачи часто удобнее получить артефакт непосредственно из registry. Собственные runners должны очищать временные данные между заданиями.

Создаём первый перечень с Syft

Syft умеет исследовать контейнерные образы и файловые системы, а также выводить результаты в распространённых форматах. Для обмена с другими системами удобно выбрать CycloneDX JSON или SPDX, учитывая возможности получателя.

Задайте IMAGE_REF полной ссылкой на свой образ с digest. Затем выполните:

syft scan "registry:$IMAGE_REF" \
  -o cyclonedx-json=sbom.cdx.json

Переменная должна содержать реальный адрес вашего артефакта, а не изменяемый тег. Для закрытого registry настройте чтение через предусмотренный механизм учётных данных. Не включайте пароль в URL образа и командные журналы.

Проверьте, что файл создан, имеет корректный JSON и содержит компоненты. При установленном jq можно вывести небольшой список:

jq -r '.components[]? | [.name, .version, .purl] | @tsv' sbom.cdx.json

Пустой результат не обязательно означает отсутствие зависимостей. Возможно, выбран не тот объект, не поддержан способ упаковки или сканер не нашёл ожидаемые метаданные. Сопоставьте результат с несколькими компонентами, наличие которых вы точно знаете.

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

Сначала найдите основной runtime: например, интерпретатор Python или Node.js, если он действительно присутствует в образе. Затем проверьте системные библиотеки и несколько прямых зависимостей приложения. Обратите внимание на версии и идентификаторы пакетов.

Одинаковое имя не всегда означает один и тот же компонент. В разных экосистемах могут существовать пакеты с похожими названиями. Формат purl помогает описать происхождение пакета более точно, чем одна строка name.

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

Состав и назначение формата описаны в документации CycloneDX. Не удаляйте неизвестные поля ради красивого компактного файла, если документ затем использует автоматический анализатор. Лучше хранить полный оригинал и отдельное представление для человека.

SBOM и поиск уязвимостей — два шага

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

grype sbom:sbom.cdx.json --output table

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

Не воспринимайте число Critical как единственную характеристику риска. Уточните, относится ли проблема к найденному пакету, доступна ли уязвимая функция и существует ли исправление. Для пакетов дистрибутива учитывайте исправления, которые поставщик переносит без изменения основной версии upstream.

При этом неизвестная достижимость не является автоматическим основанием игнорировать предупреждение. Зафиксируйте решение и ответственного. Если временно принимаете риск, укажите срок пересмотра и причину, а не добавляйте бессрочное исключение с комментарием «мешает сборке».

Разбор без найденных уязвимостей тоже полезен

Первый отчёт может оказаться пустым. Это хороший повод проверить охват, а не объявлять приложение неуязвимым. Возьмите пакет, присутствие которого точно известно по сборке, и найдите его имя и версию в SBOM. Затем убедитесь, что сканер действительно загрузил актуальную базу и анализировал созданный документ, а не соседний файл от прошлого выпуска.

Сохраните число найденных компонентов как диагностический ориентир. Резкое падение с сотен до нескольких строк после смены сборки иногда означает, что изменилась упаковка и инструмент перестал видеть часть зависимостей. Это не обязательно ошибка, но требует объяснения. Проверяемый перечень состава ценен именно тем, что его полноту можно обсуждать отдельно от сегодняшнего списка известных проблем.

Сравниваем два выпуска

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

Разницу интерпретируйте в контексте сборки. Новый системный пакет мог появиться из-за изменения базового образа, а исчезновение библиотеки — из-за перехода на статическую сборку, где метаданные обнаруживаются иначе. Не объявляйте каждое исчезновение улучшением безопасности без проверки.

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

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

Храним доказательства вместе с выпуском

Для каждого выпуска сохраняйте digest образа, SBOM, версию сканера и результат проверки. Не называйте файл только sbom-latest.json, если через месяц понадобится разобраться с установленной исторической версией.

Разместите документы в защищённом хранилище артефактов или используйте поддерживаемую привязку к контейнерному реестру. Если нужна проверка происхождения, подпишите соответствующие сведения и проверяйте их связь с тем же digest. Наличие файла рядом с образом ещё не доказывает, кто его создал.

Проверьте политику очистки. Registry или CI могут удалить старые артефакты раньше, чем закончится срок эксплуатации приложения. История состава должна сохраняться столько, сколько она нужна для сопровождения и расследований.

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

Небольшое упражнение для команды

Выберите одну известную библиотеку и найдите её путь в готовом образе. Затем обновите её на тестовой ветке, пересоберите контейнер и убедитесь, что новая версия появилась в SBOM. Проверьте также, не осталась ли старая копия в другом месте.

Следующий шаг — взять образ, который сейчас запущен на тестовом VPS, и сопоставить его digest с сохранённым перечнем. Это связывает отчёт с эксплуатацией. Без такой связи можно годами сканировать прекрасные новые сборки и продолжать обслуживать посетителей старым контейнером.

Назначьте человека, который разбирает новые предупреждения, и понятное время реакции. Автоматический отчёт полезен, когда у него есть получатель и следующий шаг. Иначе файл SBOM становится ещё одним приложением к сборке, которое все успешно научились не открывать.

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