Заказчик запросил SBOM: команда впервые выясняет, из чего собран продукт

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

Команда серверной разработки готовит свой список. Разработчики клиентской части свой. Специалисты по эксплуатации добавляют компоненты из образа контейнера.

Затем выясняется, что есть еще транзитивные зависимости, а точные версии некоторых библиотек приходится восстанавливать.

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

Почему перечня библиотек недостаточно

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

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

Для этой задачи используют SBOM (Software Bill of Materials) — формализованную запись со сведениями о компонентах, использованных при создании ПО, и связях между ними в цепочке поставки.

Именно такое определение дает NIST.

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

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

Реестр компонентов, SBOM и анализ состава ПО: в чем разница

Эти инструменты решают связанные, но разные задачи. Реестр компонентов показывает, какие сторонние решения и библиотеки используются в разработке.

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

Например, позволяет установить, какая версия библиотеки вошла в определенную сборку вместе с ее зависимостями. Анализ состава ПО помогает выявлять риски в сторонних компонентах, в том числе известные уязвимости.

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

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

Как это должно работать

Здесь полезно разделить два процесса.

1. При выпуске продукта

Сборка формирование SBOM привязка к релизу сохранение сведений о составе. Так компания знает, что именно вошло в выпущенную версию. Для автоматизированной обработки SBOM используются стандартные форматы: SPDX, CycloneDX и SWID.

2. При обнаружении новой уязвимости

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

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

Что проверить перед следующим запросом заказчика

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

• определить сторонние компоненты и их версии;
• увидеть транзитивные зависимости и компоненты образа контейнера;
• связать состав с конкретной сборкой;
• установить, какие релизы потенциально затронуты при обнаружении уязвимости в используемом компоненте?

Если для ответа приходится восстанавливать историю разработки, проблема уже обнаружена.

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