CISA опубликовала проект обновлённых минимальных требований к SBOM — списку компонентов, из которых собран программный продукт. Для тех, кто разрабатывает, продаёт или закупает софт, новость практическая: документ делает инвентаризацию глубже, но не снимает главный вопрос ИБ-команд — как превратить этот список в реальное снижение риска, а не в ещё один файл для отчёта.
Это не новый международный стандарт, а проект рекомендаций CISA
22 августа 2025 года CISA вынесла на обсуждение проект 2025 Minimum Elements for a Software Bill of Materials. Это обновление базовых требований NTIA 2021 года, а не новый обязательный стандарт и не совместный документ «17 государственных структур», как можно было понять из исходного текста.
Dark Reading пишет, что рынок встретил документ без восторга, но и без отторжения: идея понятная, польза от прозрачности цепочки поставок тоже, а вот с практическим применением по-прежнему есть вопросы. Комментарии к проекту CISA собирала до 3 октября 2025 года.
Какие поля CISA добавила в SBOM
В проекте появились новые обязательные элементы: хеш компонента, сведения о лицензии, название инструмента генерации и контекст генерации. Параллельно CISA уточнила уже знакомые поля: кто именно произвёл компонент, кто сформировал сам SBOM, как описывать версии и идентификаторы, а также как фиксировать охват зависимостей.
Самое полезное изменение для практики — акцент не только на прямых, но и на транзитивных зависимостях. Проще говоря, речь уже не о том, что приложение подтянуло напрямую, а о всей цепочке библиотек, где обычно и всплывают неприятные сюрпризы с уязвимостями.
Почему эксперты всё равно спорят о ценности SBOM
По данным Dark Reading, эксперты положительно оценивают машинно-читаемые форматы вроде SPDX и CycloneDX, а также требование указывать хеши компонентов. Это делает SBOM удобнее для автоматической проверки и помогает понять, не подменили ли артефакт после сборки.
Но проблема глубже: сам по себе SBOM не отвечает, насколько опасна конкретная уязвимость для вашего продукта. Если команда получает сотни совпадений по пакетам, а потом вручную разбирается, что из этого реально эксплуатируемо, список компонентов превращается не в инструмент защиты, а в генератор лишней срочности.
Именно поэтому спор вокруг SBOM крутится уже не вокруг формата файла, а вокруг качества данных, автоматизации и связи с процессами управления уязвимостями. Длинный JSON ещё не означает управляемый риск.
Что это значит для рынка России и СНГ
Для поставщиков B2B-софта сигнал прямой: крупные заказчики будут всё чаще просить не просто SBOM, а SBOM в стандартном формате, с понятным охватом зависимостей и регулярным обновлением. Для DevOps- и платформенных команд это означает более жёсткую автоматизацию сборки и учёта компонентов в CI/CD.
Для тех, кто покупает программные продукты, минимальный вопрос теперь звучит так: можно ли по этому SBOM быстро понять, затронут ли продукт новой CVE и что с этим делать. Если нельзя, документ полезен примерно как инструкция без страниц с ошибками.
Следующий шаг для рынка очевиден: не добавлять поля ради полей, а научиться проверять полноту SBOM и связывать его с реальной эксплуатацией уязвимостей.
Источники: Dark Reading, уведомление CISA в Federal Register.