Четверг, 14:30. Пентест веб-приложения для заказчика из healthcare-сектора США. В зависимостях Spring Boot - транзитивная библиотека четвёртого уровня вложенности с критической уязвимостью, публичный PoC к которой лежит в открытом доступе полгода. Вендор о ней не знал: дерево зависимостей отслеживалось через таблицу Excel, и transitive deps проваливались сквозь учёт как вода сквозь решето. На ручной разбор ушло три часа - при наличии machine-readable SBOM одна команда
grype sbom.json дала бы ответ за секунды. Этот кейс воспроизводится из проекта в проект. По данным CISA, отсутствие прозрачности в компонентах ПО - системная проблема безопасности цепочки поставок. Именно поэтому SBOM и Secure by Design стали центральными требованиями к вендорам, поставляющим софт в регулируемые отрасли.От EO 14028 к 2025: эволюция требований CISA к вендорам
Executive Order 14028 ("Improving the Nation's Cybersecurity") в 2021 году запустил процесс: Министерство торговли получило поручение разработать руководство по supply chain security, включая минимальные элементы software bill of materials. В том же году NTIA опубликовала документ "The Minimum Elements For a Software Bill of Materials" с семью базовыми полями - Supplier Name, Component Name, Version, Unique Identifier, Dependency Relationship, Author of SBOM Data, Timestamp.С 2022 года директива OMB обязала федеральные агентства требовать SBOM от поставщиков ПО в соответствии с руководством CISA. Параллельно в предложенном правиле FAR (Cyber Threat and Incident Reporting and Information Sharing Rule) SBOM упоминается как обязательный элемент для государственных контрактов. Финансовый контекст тут прямой: вендор без SBOM рискует потерять федеральные контракты, а для компаний, ориентированных на госсектор, это десятки процентов выручки.
К 2025 году, по отраслевым оценкам, порядка 60% организаций критической инфраструктуры требуют software bill of materials от поставщиков (в 2022 этот показатель не превышал 20%). В ЕС аналогичные обязательства вводит Cyber Resilience Act (CRA), требующий от производителей документировать компоненты ПО (CRA Annex I, Part II § 1). То есть SBOM - уже не американская причуда, а глобальный тренд.
2025 Minimum Elements: четыре новых обязательных поля
22 августа 2025 года CISA опубликовала проект "2025 Minimum Elements for a Software Bill of Materials", развивающий стандарт NTIA 2021 года. Четыре новых элемента:| Элемент | Назначение для SOC/пентеста |
|---|---|
| Component Hash | Верификация целостности - хеш позволяет обнаружить подмену бинаря (T1554, Persistence) |
| License | Автоматическое определение copyleft-рисков и юридических обязательств |
| Tool Name | Оценка полноты SBOM - инструмент генерации влияет на качество результата |
| Generation Context | Воспроизводимость - контекст сборки для корреляции SBOM с конкретным билдом |
Документ разделяет роли SBOM Author и Software Producer. В крупных проектах SBOM генерирует CI/CD-пайплайн или подрядчик, но ответственность за полноту и достоверность лежит на вендоре. Для Blue Team это означает: при incident response претензии идут к Software Producer, а не к CI-системе. Кто подписался - тот и отвечает.
Параллельно CISA выпустила интерактивный инструмент "Guide for Software Acquisition" - он переводит стандарты безопасной разработки CISA в конкретный язык закупочных контрактов. Минимальная формулировка для RFP, согласно этому руководству:
Это уже не абстрактное "vendor must follow industry best practices" - это верифицируемые поля и форматы. Можно взять SBOM и за минуту проверить, все ли поля на месте.
3 сентября 2025 года CISA и NSA совместно с партнёрами опубликовали "A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity", подписанный 21 агентством из 15 стран. SBOM перестаёт быть исключительно американским требованием - теперь это международная история.
Secure by Design и аудит SBOM: VEX, SCA и проверка стороннего ПО
Secure by Design - набор принципов CISA, к которым вендоры присоединяются через Secure by Design pledge. SBOM - одно из обязательств: вендор обеспечивает прозрачность компонентов ПО на всём жизненном цикле продукта.На практике secure by design принципы требуют:
- SBOM при каждом релизе - привязка к конкретной версии, билду и контексту сборки
- Стандартный формат - CycloneDX (OWASP, нативная поддержка VEX) или SPDX (Linux Foundation, ISO/IEC 5962)
- Полное покрытие - open-source, коммерческие библиотеки, SDK, firmware, контейнеры, криптографические стеки
- Post-release мониторинг - сканирование SBOM после деплоя, а не только при сборке
VEX: фильтр шума для уязвимостей цепочки поставок
Vulnerability Exploitability eXchange (VEX) отвечает на вопрос: "Найденная CVE в компоненте - она реально эксплуатируема в нашем продукте?" Без VEX SBOM генерирует шум: сканер находит 200 CVE в зависимостях, 180 из которых не применимы - уязвимый code path не задействован, конфигурация не затронута. Разгребать 200 алертов, из которых 90% мусор - сомнительное удовольствие.| VEX-статус | Значение | Что проверять при пентесте |
|---|---|---|
| affected | Уязвимость эксплуатируема | Приоритет - проверка эксплуатируемости на стенде |
| not_affected | Уязвимый код не задействован | Проверить rationale - действительно ли code path недоступен |
| fixed | Исправлено в этой версии | Верифицировать, что патч применён корректно |
| under_investigation | Анализ не завершён | Красный флаг - вендор не может оценить риск |
VEX-запись
not_affected без обоснования - слабое доказательство. При аудите SBOM я всегда проверяю VEX-обоснования: если вендор заявил not_affected, но путь до уязвимой функции реально достижим - это находка для отчёта. Заявлено «не затронуто» - реально затронуто. Такое встречается чаще, чем хотелось бы.Software Composition Analysis (SCA) дополняет связку: SCA-инструменты автоматически сканируют SBOM и выявляют компоненты с известными уязвимостями. SBOM - статичный артефакт (список), SCA - активный процесс (сканирование). Комбинация SBOM + SCA + VEX - то, что OWASP DevSecOps Maturity Model (DSOMM) описывает как зрелый подход к third-party risk management.
Пентест поставляемого софта: как SBOM меняет скоупинг атаки
Для пентестера SBOM - карта атаки, не комплаенс-документ. Machine-readable список всех компонентов с версиями и хешами позволяет перейти от дней разведки к минутам.Бизнес-логика атаки на supply chain: злоумышленник компрометирует одну зависимость - получает доступ ко всем продуктам, которые её используют. Радиус поражения огромен: одна уязвимая библиотека может сидеть в сотнях продуктов. MITRE ATT&CK выделяет Supply Chain Compromise (T1195, Initial Access) как самостоятельное семейство техник - и не зря.
Маппинг SBOM на MITRE ATT&CK
| Техника ATT&CK | Что проверять через SBOM |
|---|---|
| Compromise Software Dependencies (T1195.001) | Diff SBOM между релизами - неожиданные новые зависимости |
| Compromise Software Supply Chain (T1195.002) | Верификация хешей компонентов против эталонов |
| Compromise Host Software Binary (T1554) | Сопоставление развёрнутых бинарей с SBOM-хешами |
| Code Signing Certificates (T1587.002) | SBOM фиксирует ожидаемых suppliers - подпись от неизвестного поставщика = алерт |
| Vulnerabilities (T1588.006) | Сканирование SBOM на CVE - какие уязвимости доступны атакующему |
При пентесте стороннего ПО эта таблица работает как чеклист: для каждой техники проверяешь, насколько вендор контролирует supply chain своих зависимостей.
Генерация и проверка SBOM в CI/CD - пошагово
Шаг 3 - continuous monitoring через Dependency-Track. Платформа принимает SBOM через API, индексирует компоненты и мониторит новые CVE. Когда в NVD появляется уязвимость, затрагивающая компонент из SBOM - алерт приходит автоматически. Это закрывает требование CISA о post-release monitoring.
Типичная ошибка (и я видел её не раз): SBOM сохраняется как CI-артефакт с экспайром через 30 дней, а продукт поддерживается годами. SBOM нужно хранить весь период поддержки продукта - в артефакт-репозитории рядом с билдом. Иначе через полгода у вас нет ни SBOM, ни понимания, из чего собран продакшн.
Detection: как SOC отслеживает уязвимости цепочки поставок через SBOM
Для Blue Team SBOM - инструмент проактивного мониторинга. Три сценария, которые стоит отработать:Сценарий 1: zero-day в транзитивной зависимости. Публикуется критическая CVE в широко используемой библиотеке. SOC-аналитик запрашивает Dependency-Track: "Какие продукты содержат эту библиотеку?" Ответ - за секунды: список затронутых продуктов с версиями. Без SBOM процесс занимает дни: команды разработки проверяют проекты вручную, часть не знает о transitive dependencies четвёртого-пятого уровня. Вспомните Log4Shell - кто тогда за день нашёл все свои инстансы log4j? Вот именно.
Сценарий 2: обнаружение supply chain compromise. Между релизами v2.3 и v2.4 в SBOM появляется компонент, который не проходил security review. Diff двух SBOM-файлов выявляет аномалию:
Bash:
diff <(jq '.components[].name' sbom-v2.3.json | sort) \
<(jq '.components[].name' sbom-v2.4.json | sort)Сценарий 3: корреляция с threat intelligence. Threat intel фид сообщает о компрометации npm-пакета. SOC коррелирует название и версию пакета с инвентарём SBOM всех развёрнутых продуктов. Пакет найден - немедленная эскалация, блокировка обновлений до верификации хешей.
NIST определяет три уровня зрелости SBOM-процесса: базовый (минимальные элементы NTIA), рекомендуемый (хеши, лицензии, контекст генерации - то, что добавил документ CISA 2025) и продвинутый (интеграция с VEX, автоматический мониторинг, двусторонний обмен данными между вендором и заказчиком). Продвинутый уровень - то, к чему стремятся организации с выстроенным SOC: когда VEX от вендора автоматически обновляет статус CVE в Dependency-Track и триггерит playbook в SOAR.
Большинство вендоров, с которыми я сталкивался при аудитах, воспринимают SBOM как PDF для compliance-отдела заказчика. Сгенерировали раз на этапе пресейла, приложили к документации, забыли. Но SBOM, который не обновляется при каждом релизе и не сканируется после деплоя - бесполезный артефакт. Он даёт ложное ощущение прозрачности, не обеспечивая реальной безопасности цепочки поставок ПО. Через полгода состав зависимостей уходит от зафиксированного SBOM настолько, что документ описывает другой продукт.
Мой прогноз: через полтора года SBOM станет обязательным входным артефактом для пентеста стороннего ПО, как сейчас обязательна документация по API. Пентестер без SBOM тратит время на то, что вендор обязан раскрыть. Пентестер с SBOM фокусируется на проверке того, что вендор заявил - и на поиске того, чего в SBOM нет, но быть должно. Именно разрыв между «заявлено» и «реально» - самая продуктивная зона для обнаружения проблем.
Проверьте свой pipeline:
syft + grype прикручиваются за час, Dependency-Track поднимается в Docker за вечер. Если через неделю после этого вы не найдёте хотя бы одну забытую библиотеку с известной CVE - я удивлюсь. Если в вашем SOC обсуждается интеграция SBOM-мониторинга в detection-процессы и корреляция с CVE-фидами - на codeby.net ведётся тред с разбором подобных кейсов и обменом наработками по автоматизации.
