SBOM показывает состав продукта. Безопасность — нет
Представим обычную ситуацию.
Публикуется информация о критической уязвимости в популярной библиотеке. Руководство спрашивает информационную безопасность: используем ли мы этот компонент и насколько велик риск?
Компания уже внедрила генерацию SBOM. Формально ответ должен находиться за несколько минут.
Но вместо ответа начинаются новые вопросы.
В каких продуктах присутствует компонент? Какая версия действительно развёрнута в промышленной среде? Достижим ли уязвимый код? Кто владеет продуктом? Есть ли компенсирующие меры? Когда поставщик выпустит исправление? Можно ли временно отключить опасную функцию?
Наличие SBOM помогает начать расследование. Но не завершает его.
Именно здесь проходит граница между прозрачностью состава и управлением риском.
SBOM — это карта, а не сертификат безопасности
NIST определяет SBOM как формальную запись, содержащую сведения о компонентах, использованных при создании программного обеспечения, и связях между ними. Это важная основа: без знания состава продукта трудно быстро определить потенциальное влияние новой уязвимости. (NIST)
Но из определения не следует, что каждый компонент:
- получен из доверенного источника;
- проверен на наличие вредоносных изменений;
- собран в защищённой среде;
- действительно используется во время исполнения;
- не содержит неизвестных уязвимостей;
- своевременно обновляется;
- сопровождается поставщиком;
- имеет назначенного владельца риска.
SBOM отвечает преимущественно на вопрос: «Что предположительно находится внутри продукта?»
Для управления риском нужны дополнительные ответы:
Где это используется? Может ли уязвимость быть эксплуатирована? Насколько критичен продукт? Кто должен принять решение? Что организация способна сделать сейчас?
В августе 2025 года CISA опубликовала проект обновлённых минимальных элементов SBOM, повысив ожидания к качеству и применимости данных по сравнению с базовой моделью NTIA 2021 года. Это показательный сдвиг: рынок постепенно переходит от самого факта наличия SBOM к его полноте, актуальности и практической ценности. (CISA)
Иллюзия № 1. Если SBOM сгенерирован, значит состав известен
SBOM может быть технически корректным и при этом неполным.
Разные инструменты анализируют разные источники: файлы зависимостей, исходный код, контейнерный образ, бинарный артефакт или уже развёрнутую систему. Поэтому результаты могут отличаться.
В SBOM могут не попасть:
- динамически загружаемые компоненты;
- вручную добавленные библиотеки;
- системные пакеты базового образа;
- встроенные бинарные зависимости;
- плагины и расширения;
- JavaScript, загружаемый с внешней стороны;
- компоненты, появившиеся после сборки;
- зависимости, используемые инфраструктурой AI- или ML-продукта.
Кроме того, даже полный SBOM быстро теряет ценность, если он не обновляется вместе с релизом.
Файл шестимесячной давности может точно описывать продукт, которого больше нет.
Поэтому первый показатель зрелости — не количество созданных SBOM, а доля промышленных релизов, для которых существует актуальный и проверяемый SBOM.
Иллюзия № 2. Наличие уязвимого компонента означает уязвимость продукта
После сопоставления SBOM с базой уязвимостей компания может получить тысячи совпадений.
Это ещё не означает, что тысячи уязвимостей могут быть эксплуатированы.
Библиотека может присутствовать в поставке, но уязвимая функция не вызывается. Компонент может использоваться только во время сборки. Опасный интерфейс может быть недоступен из атакуемого контура. Уязвимость может требовать конфигурации, которой нет в конкретном продукте.
Если рассматривать каждое совпадение как одинаково критичное, SBOM становится генератором очередного потока уведомлений.
Для разделения факта наличия компонента и факта влияния уязвимости используется VEX — машиночитаемая информация о том, затронут ли конкретный продукт конкретной уязвимостью. CISA рассматривает VEX как дополнение к SBOM, позволяющее передавать статусы вроде affected, not affected, fixed или under investigation. (CISA)
Однако и VEX не следует принимать на веру автоматически. Утверждение «not affected» должно иметь понятное обоснование, источник и срок актуальности.
Зрелый подход объединяет:
наличие компонента + достижимость уязвимого кода + конфигурацию + доступность функции + защитные меры + критичность продукта.
Иллюзия № 3. Если известных CVE нет, компонент безопасен
Отсутствие записи в базе уязвимостей означает только то, что организации неизвестна подходящая опубликованная запись.
Компонент может:
- быть вредоносным изначально;
- поступить из поддельного репозитория;
- быть подменён во время сборки;
- содержать незарегистрированную уязвимость;
- поддерживаться одним разработчиком без устойчивого процесса обновления;
- иметь сомнительное происхождение;
- отличаться от версии, заявленной в метаданных.
SBOM показывает идентичность компонента, если она корректно установлена. Но он не доказывает целостность всей цепочки от исходного кода до полученного артефакта.
Для этого нужны другие механизмы: управление доверенными репозиториями, цифровая подпись, проверка артефактов, attestations, защищённые build runners, контроль изменений и сведения о provenance.
Например, SLSA предназначен для оценки и последовательного повышения защищённости software supply chain, включая гарантии происхождения и целостности сборки. Это дополняет SBOM, но не заменяется им. (Open Source Security Foundation)
Иллюзия № 4. SBOM описывает безопасность процесса сборки
Можно получить абсолютно точный перечень компонентов из уже скомпрометированного артефакта.
Все версии будут указаны правильно. Формат будет валидным. Файл пройдёт автоматическую проверку.
Но если учётные данные CI/CD были похищены, сборочный скрипт изменён или артефакт подменён после формирования SBOM, корректный список компонентов не поможет обнаружить саму компрометацию.
SBOM не отвечает на вопросы:
- кто инициировал сборку;
- из какой версии исходного кода;
- в какой среде;
- с какими параметрами;
- какие действия выполнялись в pipeline;
- совпадает ли поставленный артефакт с ожидаемым;
- был ли SBOM сформирован для того же объекта, который получил заказчик.
Поэтому зрелая программа software supply chain security не может состоять из одного генератора SBOM.
NIST рассматривает SBOM как один из элементов более широкой системы secure software development и управления цепочкой поставок. На июль 2026 года SSDF 1.1 остаётся финальной версией, а SSDF 1.2 опубликован как проект, что также подчёркивает развитие комплексного, а не артефактного подхода. (NIST Computer Security Resource Center)
Иллюзия № 5. Найденный компонент автоматически превращается в управленческое решение
Предположим, анализ показал: критичная библиотека присутствует в 18 системах.
Что дальше?
Без связи SBOM с asset inventory и product inventory организация не знает:
- какие из этих систем находятся в промышленной эксплуатации;
- какие поддерживают критичные бизнес-процессы;
- какие доступны извне;
- где хранятся чувствительные данные;
- кто является владельцем продукта;
- кто вправе остановить сервис;
- кто принимает остаточный риск;
- где допустимо срочное обновление, а где требуется длительное тестирование.
Техническое обнаружение компонента должно превращаться в очередь управленческих решений, а не просто в очередь тикетов.
Для этого каждому продукту нужны как минимум:
- бизнес-владелец;
- технический владелец;
- владелец риска;
- критичность и допустимое время простоя;
- актуальная информация о среде эксплуатации;
- согласованный сценарий экстренного обновления;
- правила применения компенсирующих мер.
Без этого SBOM повышает видимость проблемы, но не обязательно сокращает риск.
Иллюзия № 6. Для procurement достаточно потребовать файл
Требование «поставщик должен предоставить SBOM» легко включить в анкету или договор.
Гораздо труднее определить, что организация будет делать с полученным файлом.
Procurement должен оценивать не только наличие SBOM, но и способность поставщика поддерживать его жизненный цикл:
- для каких версий продукта формируется SBOM;
- как быстро он обновляется после релиза;
- насколько глубоко раскрываются транзитивные зависимости;
- как исправляются ошибки в составе;
- предоставляется ли VEX;
- как поставщик уведомляет об уязвимостях;
- какие SLA действуют для критичных проблем;
- как подтверждается provenance;
- как долго поддерживаются версии;
- кто отвечает во время инцидента.
Актуальное руководство CISA по приобретению программного обеспечения отдельно соединяет требования к машиночитаемому SBOM с vulnerability management, VEX, защищённой сборкой, контролем сторонних компонентов и процессами реагирования поставщика. (CISA)
Иначе компания приобретает не способность управлять риском, а ещё один файл, который нужно где-то хранить.
Лестница зрелости использования SBOM
Уровень 0. Невидимость
SBOM отсутствует. На вопрос о наличии компонента команды отвечают вручную, просматривая репозитории, контейнеры и документацию.
Уровень 1. Compliance-артефакт
SBOM генерируется для аудита или требования заказчика. Он хранится отдельно от процессов разработки и эксплуатации. Полнота и актуальность системно не контролируются.
Уровень 2. Управляемая инвентаризация
SBOM формируется автоматически для каждого релиза, имеет версию, связан с конкретным артефактом и проходит проверку качества. Организация может быстро найти продукты, содержащие определённый компонент.
Уровень 3. Контекст риска
Данные SBOM сопоставляются с уязвимостями, VEX, reachability, конфигурацией и критичностью активов. Приоритет определяется не только CVSS, но и реальным контекстом эксплуатации.
Уровень 4. Операционный контроль
Обнаружение значимого компонента автоматически запускает процесс: определяются владельцы, создаются задачи, применяются SLA, оцениваются компенсирующие меры и фиксируется решение о риске.
Уровень 5. Software supply chain assurance
SBOM связан с provenance, подписями, attestations, контролем сборочной среды, политиками допуска компонентов и оценкой поставщиков. Руководство измеряет не количество файлов, а скорость и качество принятия решений.
Семь вопросов к вашему SBOM
Чтобы понять реальную зрелость, я бы предложил не спрашивать: «Есть ли у нас SBOM?»
Гораздо полезнее задать семь других вопросов.
- Как мы проверяем, что SBOM полный и относится именно к поставленному артефакту?
- Сколько времени требуется, чтобы найти все промышленные продукты с конкретным компонентом?
- Умеем ли мы отличить наличие уязвимой библиотеки от реальной эксплуатируемости?
- Связан ли каждый результат с владельцем продукта и критичностью бизнес-процесса?
- Можем ли мы проверить происхождение компонента и целостность сборки?
- Обязан ли поставщик обновлять SBOM и сообщать статус уязвимости в установленный срок?
- Какое реальное решение мы способны принять в течение суток после обнаружения критичного компонента?
Последний вопрос — главный.
Если компания может только открыть файл и увидеть название библиотеки, у неё есть прозрачность.
Если она способна определить влияние, найти владельца, выбрать меру, установить срок и проконтролировать исполнение — у неё появляется управление риском.
Авторская позиция
SBOM — это карта состава, а не сертификат безопасности. Карта полезна только тому, кто знает, какой маршрут проверить, кто отвечает за решение и что делать после обнаружения проблемы.
Я не считаю количество сгенерированных SBOM хорошей метрикой зрелости.
Более честные показатели:
- время от публикации критичной уязвимости до определения затронутых продуктов;
- доля релизов с актуальным и проверенным SBOM;
- доля компонентов, для которых определены происхождение и владелец;
- время получения позиции поставщика;
- доля критичных совпадений, для которых оценена эксплуатируемость;
- время от обнаружения до принятого и исполненного решения;
- количество исключений, которые остаются без владельца и срока.
SBOM не должен завершать разговор о software supply chain security.
Он должен этот разговор начинать.
Потому что настоящая ценность прозрачности проявляется не в момент создания списка компонентов, а в момент, когда организация обнаруживает проблему и должна быстро решить, что делать дальше.
Подписывайтесь на мой ТГ канал: @ib_decisions