Перечень компонентов программного обеспечения (SBOM)

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

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

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

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

• Быстрый анализ влияния уязвимости
• Соблюдение лицензионных требований и отслеживание обязательств
• Прозрачность цепочки поставок для клиентов и аудиторов

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

• SPDX — стандарт Linux Foundation, ориентированный на лицензирование и широко принятый регулирующими органами
• CycloneDX — стандарт OWASP, ориентированный на безопасность и поддерживающий данные об уязвимостях и связях между зависимостями

Не изобретайте собственный формат: потребители и средства сканирования ожидают именно эти форматы.

Каждая запись о компоненте должна содержать достаточно данных для идентификации, чтобы её можно было сопоставить с источниками данных об уязвимостях. Основные поля:

• имя и версия — точные, а не диапазон
• PURL (адрес пакета) — универсальный идентификатор, например pkg:npm/lodash@4.17.21
• хеш — для проверки целостности
• лицензия — идентификатор лицензии SPDX
• поставщик — тот, кто это создал

Создавайте SBOM автоматически из исходного кода или собранного артефакта. Syft — распространённый генератор для разных экосистем, который поддерживает оба стандарта.

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

• SBOM исходного кода — то, что заявлено в манифесте; может не учитывать объединённый в пакет или включённый в проект код
• SBOM сборки — то, что фактически включила сборка; наиболее точный вариант для выпуска
• SBOM среды выполнения / развёрнутой системы — то, что фактически присутствует в работающем образе, включая пакеты OS

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

SBOM становится особенно полезной, если передать её сопоставителю, который связывает компоненты с известными CVEs. Это отделяет создание от анализа: сканируйте старую SBOM в день публикации новой CVE.

SBOM может показать уязвимый компонент, который фактически нельзя эксплуатировать в Вашем продукте (уязвимая функция никогда не вызывается). Документ VEX (обмен сведениями об эксплуатируемости уязвимостей — eXchange) фиксирует такую оценку.

VEX снижает уровень шума: вместо того чтобы каждый клиент паниковал из-за указанной CVE, Вы публикуете заявление `not_affected` с обоснованием или `affected` с описанием устранения проблемы. Это превращает необработанный перечень в практичный процесс приоритизации.

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

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

• Создавайте SBOM из собранного артефакта, а не только из репозитория
• Храните SBOM в реестре с возможностью запросов, используя версию как ключ
• Повторно сканируйте сохранённые SBOM по расписанию с использованием свежих источников данных о CVE
• Блокируйте выпуски по результату сканирования на уязвимости

SBOM незаметно перестают приносить пользу, если относиться к ним как к формальной галочке.

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

Цель — точная, регулярно создаваемая, подписанная и непрерывно сканируемая SBOM, а не разовый файл формата JSON.

Примените изученное к сценарию инцидента.

Теперь Вы умеете составлять перечень содержимого программного обеспечения и действовать на его основе.

• SBOM — это машиночитаемый список каждого компонента в формате SPDX или CycloneDX
• Идентифицируйте компоненты по PURL, версии, хешу и лицензии
• Создавайте SBOM во время сборки, затем передавайте её сопоставителю (grype, osv-scanner) для поиска CVEs
• Используйте VEX, чтобы указать фактическую возможность эксплуатации и сократить число ложных тревог
• Подписывайте и автоматизируйте работу в среде непрерывной интеграции; повторно сканируйте сохранённые SBOM по новым источникам данных

Далее Вы узнаете, как с помощью подписей подтвердить происхождение артефактов.