Сообщить об ошибкеКороткий ответ
SBOM — это машиночитаемый «список состава» артефакта (всех включённых библиотек и их версий); при обнаружении новой уязвимости в конкретной библиотеке SBOM позволяет быстро найти все артефакты и сервисы, где она используется, без повторного ручного анализа каждого проекта.
Как это работает подробнее
при сборке образа или пакета SBOM-генератор (Syft, cdxgen) анализирует все установленные зависимости и их точные версии и сохраняет результат в стандартном формате (SPDX, CycloneDX) рядом с артефактом или в отдельном реестре. Это снимок состава на момент сборки, независимый от последующего сканирования уязвимостей.
Пример кода
security-example-458.sh
syft packages myapp:2.3.0 -o cyclonedx-json > sbom.json
grep -A2 '"name": "log4j-core"' sbom.json
{
"name": "log4j-core",
"version": "2.14.1"
}Что использовать на практике
- Практика. SBOM хранят централизованно для всех выпущенных артефактов и прогоняют через него поиск при появлении новой громкой уязвимости (как в случае с Log4Shell) — вместо того, чтобы вручную проверять каждый сервис, делают запрос по всем SBOM на наличие конкретной библиотеки и версии. SBOM также требуют некоторые заказчики/регуляторы как часть договорных или compliance-обязательств.
- Проверка. Ожидаемое поведение: при объявлении новой критичной CVE в log4j-core 2.14.1 команда может за секунды выполнить поиск этой версии по всем сохранённым SBOM всех сервисов и получить точный список затронутых артефактов, вместо нескольких дней ручной инвентаризации зависимостей по всем репозиториям.
Подводные камни
- Ошибка. генерировать SBOM, но не хранить его централизованно и не использовать при инцидентах, превращая его в формальность «для галочки»; считать SBOM заменой сканирования на уязвимости — SBOM описывает состав, а не риски сам по себе; не обновлять SBOM при изменении зависимостей, оставляя устаревший снимок.