SBOM в CI/CD: внедрение CycloneDX, SPDX и Dependency-Track

Проблема: зависимости есть, а прозрачности нет

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

Без явного перечня обычно теряются три вещи. Во-первых, точные версии: в репозитории есть package.json или pom.xml, но в прод ушло что-то другое. Во-вторых, транзитивные зависимости: вы их не выбирали, но они попали в сборку через другие пакеты. В-третьих, происхождение: откуда пришел артефакт, какой источник использовался при сборке, какие хэши и метаданные у бинарников.

SBOM закрывает этот пробел. Это единый документ, который фиксирует состав поставки: что именно внутри, в каких версиях и как связано. Если SBOM встроен в CI/CD, вы не гадаете по логам и не ищете вручную по репозиториям, а быстро сверяете факт поставки с конкретной уязвимостью и понимаете масштаб работ.

Больше всего выигрывают команды, которым нужно действовать согласованно:

• Разработка быстрее находит, где обновлять и что может сломаться.
• Безопасность быстрее оценивает риск и приоритизирует патчи.
• ИТ-эксплуатация понимает, какие сервисы и окружения реально затронуты.
• Закупки получают прозрачные требования к составу поставляемого ПО.

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

Что такое SBOM и что в нем должно быть

SBOM (Software Bill of Materials) - это понятный список того, из чего состоит ваше приложение: какие библиотеки, модули и пакеты в него входят, и какие у них версии. Проще всего представить SBOM как "состав" на упаковке: не про то, как вы готовили продукт, а из каких компонентов он реально собран.

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

Что должно быть внутри SBOM

Минимальный набор полей, который обычно помогает и в инцидентах, и при проверках:

• название компонента (пакета/библиотеки) и его версия
• идентификатор компонента (например, package URL), чтобы избежать путаницы с "однофамильцами"
• лицензия, чтобы понимать риски использования и ограничения
• контрольные суммы (хэши) или другие признаки целостности, чтобы отличать "тот же" файл от подмененного
• источник (откуда получен компонент: реестр, репозиторий, внутренний артефакт)

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

SBOM как артефакт поставки

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

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

CycloneDX и SPDX: как выбрать формат без лишней теории

CycloneDX и SPDX решают похожую задачу - описать состав ПО, - но обычно их выбирают под разные потребности. Если важно быстро находить уязвимости в библиотеках и не тормозить релизы, чаще всего проще начать с CycloneDX. Если на первом месте юридическая чистота, лицензии и обмен документами между организациями, удобнее SPDX.

CycloneDX хорошо ложится на AppSec и DevSecOps: его часто поддерживают инструменты, которые принимают SBOM в CI/CD, строят граф зависимостей и связывают компоненты с уязвимостями. Он удобен, когда цель - быстро ответить на вопрос "где у нас используется эта версия пакета?".

SPDX сильнее в части соответствия требованиям: лицензии, авторство, поставщики, доказуемость происхождения. Это полезно, когда вы закупаете ПО у подрядчиков или сами поставляете решения крупным заказчикам и нужно формально подтвердить состав и лицензирование.

При выборе формата смотрите не на "популярность", а на то, какие поля критичны именно вам:

• точная идентификация компонента (name, version и желательно purl)
• лицензия и тип поставки (особенно для закупок и аудита)
• хэши/подписи для проверки целостности
• связь "что от чего зависит" (граф зависимостей)
• метаданные сборки (как и чем собрали, чтобы повторить)

Чтобы не усложнять старт, выберите один формат под основную цель. Типичный путь: CycloneDX для ежедневного сканирования зависимостей, а SPDX - как пакет документов для контрактов и приемки.

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

Подготовка: инвентаризация, охват и правила

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

Определите охват. Обычно в него попадают приложения (бэкенд, фронтенд, desktop), контейнерные образы, библиотеки, которые вы публикуете внутри компании, а также базовые инфраструктурные пакеты (например, агенты, утилиты, компоненты ОС в образах). Важно записать это как правило. Иначе одна команда будет делать SBOM только для кода, а другая - для всего контейнера.

Составьте карту технологий: какие языки и менеджеры пакетов реально используются (npm/yarn/pnpm, Maven/Gradle, NuGet, pip/Poetry, Go modules и т.д.). Это влияет на инструменты генерации и на качество результата. Если часть сборок не попадает в SBOM из-за "экзотики", появляются слепые зоны.

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

Заранее введите правила идентификации, чтобы не плодить дубли: единый способ писать имя компонента, версию, поставщика и тип. Даже мелочь вроде разных регистров или "react 18.2.0" против "[email protected]" потом ломает поиск и отчеты.

Назначьте владельцев. У каждого продукта должен быть ответственный за SBOM (часто тимлид или релиз-инженер), а у безопасности - роль контроля политики. Пример: команда выпускает релиз, CI собирает SBOM, а владелец подтверждает, что он сформирован для нужного артефакта и по согласованным правилам.

Как генерировать SBOM для разных типов сборок

Самый надежный путь - генерировать SBOM прямо из тех файлов, которые управляют зависимостями в сборке: манифестов и lock-файлов. Lock-файл особенно важен: он фиксирует точные версии, без него SBOM часто получается "примерным", а не пригодным для расследований.

Для библиотек и приложений (Java, .NET, Node.js, Python и т.д.) обычно достаточно опираться на манифест, lock-файл и данные сборщика. Так вы получаете и прямые, и транзитивные зависимости, а также их точные версии.

С контейнерами сложнее: важно учитывать не только ваше приложение, но и базовый образ и пакеты ОС внутри него. Частая ошибка - выпустить SBOM только для кода, забыв про OpenSSL, glibc или системные утилиты, которые тоже попадают под уязвимости. Практичный подход - делать два слоя: SBOM приложения и SBOM контейнера, а затем хранить их рядом как один набор артефактов релиза.

Чтобы SBOM был удобен в работе, заранее договоритесь об одном формате вывода для всех проектов (например, CycloneDX или SPDX) и о простой структуре артефактов: имя проекта, версия, номер сборки, хэш коммита, окружение.

Качество SBOM стоит проверять автоматически. Минимальные проверки:

• нет пустых версий и "LATEST"
• имена пакетов совпадают с экосистемой (group/artifact, npm name и т.д.)
• присутствуют транзитивные зависимости
• для контейнеров учтены пакеты ОС и базовый образ

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

Пошагово: внедряем SBOM в CI/CD

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

Минимальная схема пайплайна

Начните с простого, но повторяемого сценария:

• На этапе сборки добавьте генерацию SBOM тем же инструментом, который видит ваши зависимости (пакетный менеджер, сборщик, контейнерный билд).
• Сохраните SBOM как артефакт сборки, чтобы его можно было скачать для любой версии.
• Прикладывайте SBOM к релизному пакету (рядом с бинарником, образом или установщиком).
• Публикуйте SBOM во внутреннее хранилище артефактов или реестр, где он будет жить так же долго, как и релизы.
• Включите автоматическую проверку правил качества SBOM.

Проверки правил дают быстрый эффект. Например, запретите зависимости без фиксированной версии, пакеты из неразрешенных источников, пустые метаданные (название, версия, поставщик), а также неожиданные лицензии, если это важно для вашей организации.

Заранее решите, что ломает сборку, а что только предупреждает. Обычно провалом считают ситуации, которые делают SBOM недостоверным: не удалось собрать список зависимостей, есть компоненты с неизвестной версией, SBOM не совпадает с артефактом. Предупреждениями чаще делают то, что требует уточнения, но не блокирует релиз сразу: неполные поля, новые лицензии для ручной проверки.

Пример: команда собирает сервис, и одна библиотека подтягивается как "latest". Генератор SBOM фиксирует это как неопределенную версию, правило качества срабатывает, и сборка падает до релиза. В итоге вы не выпускаете версию, которую потом невозможно быстро сопоставить с уязвимостью в конкретной зависимости.

Хранение и целостность SBOM: чтобы ему доверяли

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

Самый практичный вариант - держать SBOM рядом с артефактом релиза в репозитории артефактов. Дополнительно можно сохранять копию в репозитории кода (например, в каталоге с релизными метаданными) или в отдельном внутреннем каталоге SBOM, если так проще управлять доступом.

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

• commit SHA и/или tag
• версия (SemVer) и build-id из CI
• имя компонента и среда (prod, stage)
• дата сборки и идентификатор пайплайна

Целостность обеспечивают хэши и подписи. Минимум - хранить SHA-256 для SBOM и проверять его в пайплайне при публикации и при скачивании. Лучше - подписывать SBOM (или подписью закрывать комплект артефактов релиза) и ограничить право публикации: только CI-сервисный аккаунт, без ручных загрузок.

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

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

Dependency-Track: анализ SBOM и разбор уязвимостей

Dependency-Track - это система, которая берет ваш SBOM и превращает его в понятную картину рисков: какие компоненты используются, где именно, и какие уязвимости к ним привязаны. Он дополняет обычные сканеры (SAST, контейнерные и IaC-сканеры): сканер находит проблемы в коде и образах, а Dependency-Track держит фокус на зависимостях и их версиях во времени. Это особенно удобно, когда SBOM в CI/CD генерируется на каждый релиз.

Импорт CycloneDX и SPDX: проекты и версии

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

Если у вас несколько сборок одного продукта (например, on-prem и cloud, разные платформы), разделите их на разные проекты или ветки версий. Иначе triage превратится в спор, что именно пострадало.

Триаж, оповещения и фиксация решений

Когда прилетает новая CVE, triage удобнее вести по простому порядку:

• Затронуты ли мы: есть ли компонент и уязвимая версия в SBOM.
• Где используется: какой сервис и какой релиз.
• Есть ли путь эксплуатации: используется ли уязвимый модуль или функция.
• Приоритет: критичность, внешняя доступность, наличие публичного эксплойта.
• План: кто делает и к какому сроку.

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

Решение фиксируйте по ходу работы: обновить зависимость, заменить компонент (если обновления нет) или принять риск с понятной причиной и сроком пересмотра. Если уязвимость есть в библиотеке, но модуль не используется, это повод поставить низкий приоритет, но оставить запись для аудита.

SBOM в закупках: требования к поставщикам и приемка

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

В тендерной документации и договорных приложениях удобно закрепить несколько пунктов:

• SBOM обязателен для поставляемого ПО и для каждого обновления (патч, минорная и мажорная версия).
• Формат на выбор: CycloneDX или SPDX, плюс указание версии схемы.
• Минимальные поля: название компонента, версия, поставщик/источник, тип (библиотека, образ, пакет), лицензия, хеши, зависимости.
• Правила для коммерческих модулей: что можно скрыть и как это помечается (например, компонент без публичного имени, но с уникальным идентификатором).
• Сроки: SBOM передается вместе с поставкой и хранится весь срок поддержки.

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

Короткий набор контрольных шагов:

• Сверить версию продукта и сборки с метаданными SBOM.
• Проверить целостность (подпись или хеш) и неизменность после передачи.
• Убедиться, что перечислены ключевые зависимости, а не только верхний уровень.
• Отметить закрытые компоненты как отдельные позиции, чтобы их можно было учитывать в рисках.
• Зафиксировать SBOM как артефакт приемки (как акт и комплект поставки).

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

Пример: как SBOM ускоряет реакцию на новую уязвимость

Представьте: утром выходит сообщение о критической уязвимости в популярной библиотеке, например в JSON-парсере. В новости часто пишут одно: "обновитесь до версии X.Y.Z". Но главный вопрос для вашей команды другой: затронуты ли ваши продукты и где именно.

Если у вас настроен SBOM в CI/CD, вы не начинаете с ручного поиска по репозиториям. Вы открываете последний SBOM для каждой сборки и за минуту находите компонент по названию и версии. В инструментах вроде Dependency-Track это обычно еще быстрее: он показывает, в каких приложениях и сборках библиотека встречается, и подсвечивает уязвимые версии.

Дальше важно не паниковать и правильно расставить приоритеты. Одна и та же библиотека может:

• реально выполняться в проде (прямой импорт, код вызывается)
• быть транзитивной зависимостью, но не использоваться по факту
• лежать в dev/test инструментах и не попадать в прод-артефакт
• присутствовать в образе или дистрибутиве, но не загружаться

В первые сутки помогает простой план:

• подтвердить, какие сборки уязвимы (по SBOM и версиям)
• понять экспозицию: интернет-доступ, затронутые сервисы, критичность данных
• выпустить патч или обновить зависимость и пересобрать артефакты
• если патча нет, включить временные меры (конфиг, WAF-правило, отключение функции)
• сообщить владельцам систем и зафиксировать статус для руководства

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

Частые ошибки и ловушки при внедрении SBOM

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

Что обычно ломает внедрение

• SBOM не привязан к версии и сборке. Если у вас нет идентификатора релиза (тег, номер сборки, хэш), то при инциденте вы тратите время на угадывание: какой именно SBOM правильный.
• Неполный состав зависимостей. Часто в отчет попадают только прямые библиотеки, а транзитивные остаются за кадром. При появлении новой уязвимости кажется, что вас это не касается, пока сканер не находит компонент в глубине дерева.
• Разнобой в именах и координатах компонентов. Одна команда пишет "log4j", другая "org.apache.logging.log4j:log4j-core". Поиск, дедупликация и сопоставление CVE начинают давать хаос.
• Слепое доверие SBOM от поставщика. Даже если документ пришел вместе с продуктом, без приемочных проверок легко получить устаревший файл или SBOM, собранный с другими флагами и репозиториями.
• Слишком жесткие правила с первого дня. Если сразу блокировать сборки по любому предупреждению, команды начнут обходить процесс или отключать генерацию.

Хорошая стартовая тактика для SBOM в CI/CD: сначала сделать покрытие и сопоставимость, а потом включать ограничения постепенно. Например, в первый месяц фиксируйте SBOM для каждого релиза и проверяйте полноту, а блокировки вводите только для критических уязвимостей и только для новых изменений. Это снижает сопротивление и дает быстрый эффект при разборе инцидентов.

Быстрый чеклист перед запуском в прод

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

Проверьте ключевые пункты:

• На каждый релиз есть SBOM, и он доступен тем, кто будет разбирать инциденты: безопасность, DevOps, владельцы продукта, поддержка.
• В составе SBOM есть точные версии и уникальные идентификаторы компонентов (например, Package URL или CPE там, где уместно), чтобы не гадать, какая именно библиотека попала в сборку.
• Учтены транзитивные зависимости, а если вы деплоите контейнеры, то добавлены компоненты образа (пакеты ОС, базовый образ). Иначе часть рисков останется за кадром.
• SBOM привязан к конкретной сборке: build-id, commit или тегу, и хранится неизменно. После релиза документ не перезаписывают, а выпускают новый для следующей версии.
• Есть понятный процесс реакции: кто смотрит алерты, кто принимает решение (обновить, компенсировать, принять риск), какие сроки для критичных уязвимостей и как фиксируется итог.

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

Следующие шаги: пилот, стандарты и поддержка внедрения

Начните с небольшого, но законченного пилота. Выберите 1-2 продукта, где есть реальная ценность от прозрачности зависимостей (например, публичный сервис и внутренний API), и доведите цепочку до конца: генерация SBOM, загрузка в хранилище, поиск уязвимостей, триаж, исправление, повторная проверка.

Хороший пилот для SBOM в CI/CD выглядит так:

• определить владельца процесса (разработка + ИБ) и SLA на разбор алертов
• зафиксировать точки генерации SBOM (сборка, релиз, контейнер)
• настроить правило: релиз без SBOM не проходит
• протестировать кейс: новая CVE в популярной библиотеке и время реакции
• подготовить отчет: что сломалось, что мешало, что автоматизировать

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

В стандарте обычно достаточно договориться о следующем:

• формат и профиль (CycloneDX или SPDX), обязательные поля и идентификаторы
• где хранится SBOM, кто имеет доступ, сколько хранить
• как подтверждать целостность (подпись, контрольные суммы, неизменяемые артефакты)
• что считать приемлемым риском и когда блокировать релиз

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

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

Если внутри не хватает рук для настройки пайплайнов, хранилищ артефактов, политики безопасности и инфраструктуры, имеет смысл подключить системного интегратора. Например, GSE.kz (gse.kz) как производитель и системный интегратор в Казахстане ведет комплексные ИТ-проекты и может помочь выстроить процессы, инфраструктуру и поддержку, включая круглосуточный сервис.