Европейский Cyber Resilience Act (Regulation (EU) 2024/2847) вступил в силу в декабре 2024 года, и в большинстве дорожных карт его записали как «проблему 2027 года»: именно с 11 декабря 2027-го заработают все требования — secure-by-design, conformity assessment, CE-маркировка, обязательный SBOM и поддержка обновлений на весь support period. Но есть более ранняя дата, которую легко пропустить, — и именно она превращает SBOM из пункта дорожной карты в операционную необходимость.
Настоящий дедлайн — 11 сентября 2026
С 11 сентября 2026 года вступают в силу обязательства по отчётности. Производитель продукта с цифровыми элементами обязан сообщать об активно эксплуатируемых уязвимостях и серьёзных инцидентах: ранний сигнал в ENISA в течение 24 часов, полное уведомление — за 72 часа, финальный отчёт — не позже 14 дней после того, как стало доступно исправление. Формально SBOM в этот момент ещё не обязателен. Но посмотрите на механику: приходит сообщение об эксплуатируемой CVE в популярной библиотеке, и у вас сутки, чтобы понять, затронут ли хоть один из ваших продуктов. Без машиночитаемого inventory компонентов это не задача на 24 часа, а паника с grep по репозиториям. Отчётность без SBOM физически невозможна — поэтому реальный дедлайн для inventory не декабрь 2027-го, а сентябрь 2026-го.
Что CRA на самом деле требует от SBOM
Вокруг требования наросли два мифа, и оба дороги. Первый — «SBOM придётся публиковать». Нет: CRA (Annex I, Part II) кладёт SBOM в техническую документацию, а раскрывается он только market surveillance authorities по обоснованному запросу. Это комплаенс-артефакт для регулятора, а не маркетинговый документ на сайте. Второй миф — «нужно перечислить всё до последней транзитивной зависимости». Закон требует минимум — top-level dependencies в общепринятом машиночитаемом формате. Перечисление вложенных под-компонентов — хорошая инженерная практика и основа для настоящего vulnerability tracking, но это ваш выбор по глубине, а не буква регламента.
Практический вывод: формат — SPDX (ISO 5962) или CycloneDX (OWASP), оба машиночитаемы и приняты индустрией. CycloneDX тяготеет к security-сценариям (несёт модель уязвимостей и VEX), SPDX — к license и legal. Сама генерация — решённая часть: syft или trivy делают SBOM из образа одной командой.
Сгенерировать SBOM — это 20% работы
Соблазн закрыть задачу одной строкой в CI обманчив. syft image:tag -o spdx-json — это лёгкие 20%. Остальные 80% — операционные:
- Хранение и привязка. SBOM, оставшийся артефактом CI-джобы, недискаверим из деплоя. Привязывайте его к образу как подписанную attestation (
cosign attest --type spdxjson) или ведите централизованно в Dependency-Track / GUAC. - Непрерывное сканирование. SBOM фиксирует состав на момент сборки, а уязвимости открывают позже. Пересканируйте хранимые SBOM (Grype, Trivy) по расписанию, а не только в момент билда — именно так вы за 24 часа найдёте затронутый продукт.
- VEX против шума. Без Vulnerability Exploitability eXchange security-бэклог тонет в false positives, и реальная эксплуатируемая CVE теряется среди сотен неприменимых. Отметка «не затронуты, потому что код не в пути исполнения» — это то, что делает 24-часовой отчёт выполнимым.
SBOM — это «что внутри», но CRA смотрит и на «как собрано»
SBOM отвечает на вопрос «из чего собран артефакт». Требование secure-by-design и устойчивости к подмене толкает ко второму вопросу — «как он собран». Здесь работает provenance в духе SLSA: проверяемая цепочка от commit до образа (кто, на каком коммите, в каком builder, чем подписано). SBOM и provenance дополняют друг друга — вместе они дают ту самую прозрачность supply chain, ради которой CRA и затевался. Хорошая новость: OpenSSF и регуляторы движутся к унификации SBOM-стандартов, так что инвестиция в CNCF-стек (Syft/Grype, Cosign, Sigstore) — это не работа в стол, а заклад под общий вектор.
Что сделать до сентября 2026
Сведите задачу к четырём пунктам, проверяемым уже сейчас. Первое — генерация SBOM на каждый build как обязательная стадия pipeline, формат CycloneDX или SPDX. Второе — хранение и attestation, чтобы SBOM находился из деплоя, а не умирал в CI. Третье — непрерывное пересканирование хранимых SBOM плюс VEX, чтобы из шума выделять эксплуатируемое. Четвёртое — организационный процесс: кто получает сигнал об активно эксплуатируемой CVE, кто за 24 часа проверяет затронутость и кто жмёт кнопку отчёта в ENISA. Первые три пункта — инструменты, которые ставятся за спринт. Четвёртый — это runbook, и именно он обычно отстаёт. До сентября 2026-го осталось меньше, чем кажется: «SBOM есть» и «по SBOM мы за сутки отвечаем регулятору» — это разные уровни готовности.