SBOM под требования ФСТЭК: как мы автоматизировали генерацию и подачу в портал регулятора

Когда в январе мы писали про обновлённые методрекомендации ФСТЭК по КИИ, там была оговорка про SBOM как отдельную историю. Вот она и пришла. С февраля 2026 года требование к SBOM для сертифицированного ПО зафиксировано в обновлённых руководящих документах регулятора - не как рекомендация, а как условие прохождения аудита. На прошлой неделе один из наших заказчиков стал первым в нашей практике объектом, который прошёл аудит с реальным SBOM-предоставлением в портал ФСТЭК. Пишем по свежим следам.

Что изменилось в РД

Обновление касается требований к производителям ПО, поставляемого на объекты КИИ и проходящего сертификацию или инспекционный контроль. Ключевые пункты:

• Состав компонентов - при каждой сертификации и плановом инспекционном контроле производитель обязан предоставить машиночитаемый SBOM для каждой версии ПО. Форматы - CycloneDX 1.5+ или SPDX 2.3+ в JSON.
• Подпись - SBOM должен быть подписан с помощью средства ЭП, сертифицированного ФСБ. На практике это ГОСТ Р 34.10-2012 и совместимые КриптоПро-инструменты.
• Передача в портал - загрузка через Личный кабинет производителя на портале ФСТЭК; портал проверяет формат и подпись автоматически при загрузке.

Требование про ФСБ-сертифицированную подпись - это то, что немного перепахало наш прежний стек. В посте про GitFlic CI мы использовали Cosign с ГОСТ-ключом в режиме sign-blob. Технически подпись ГОСТ, но Cosign сам по себе не сертифицирован ФСБ как средство ЭП. Это создаёт пробел, который на аудите мог бы стать проблемой.

Как мы перестроили пайплайн

Решение получилось гибридным. Syft по-прежнему генерирует SBOM - он хорошо справляется с анализом файловой системы, OCI-образов, JAR-файлов. Менять его не было смысла. Проблема только в слое подписи.

Для подписи мы взяли КриптоПро CSP 5.0 с утилитой cryptcp - она умеет подписывать файлы в формате CAdES-BES, что портал ФСТЭК принимает как валидную ЭП. Интеграция в GitFlic CI выглядит как отдельный stage:

sbom-sign-gost:
  stage: security
  image: registry.internal/devtools/cryptopro-csp:5.0
  needs: [sbom-generate]
  script:
    - cryptcp -sign -cert $CRYPTOPRO_CERT_THUMBPRINT
        -detached sbom.cdx.json sbom.cdx.json.sig
  artifacts:
    paths:
      - sbom.cdx.json
      - sbom.cdx.json.sig
    expire_in: 2 years

CRYPTOPRO_CERT_THUMBPRINT - переменная с отпечатком сертификата, ключ на токене в защищённом хранилище CI-окружения. Контейнер cryptopro-csp:5.0 мы собрали сами на базе AltLinux - официального образа от КриптоПро для CI-использования нет, пришлось.

Генерация Syft при этом не поменялась. Два формата параллельно, CycloneDX как основной:

sbom-generate:
  stage: security
  image: registry.internal/devtools/syft:latest
  script:
    - syft packages dir:. --output cyclonedx-json=sbom.cdx.json
        --scope all-layers
  artifacts:
    paths:
      - sbom.cdx.json
    expire_in: 2 years

Флаг --scope all-layers нужен при сканировании OCI-образов - без него Syft анализирует только верхний (squashed) слой и пропускает компоненты из промежуточных слоёв. Для директории (dir:.) флаг игнорируется, но мы его оставляем явно, так как тот же конфиг используется и для образов. ФСТЭК-портал при неполном составе выдаёт предупреждение - оно не блокирует загрузку, но остаётся в карточке инспекционного контроля.

Портал ФСТЭК: что получили на практике

Загрузка через Личный кабинет - это отдельный квест. Портал принимает пару файлов: sbom.cdx.json и sbom.cdx.json.sig. После загрузки идёт автоматическая проверка: формат, схема CycloneDX, валидность подписи по сертификату из реестра ФСБ.

Первая попытка загрузки у нас упала с ошибкой «Неверный формат подписи». Оказалось, cryptcp по умолчанию создаёт присоединённую подпись (enveloped), а портал ожидает открепленную (detached). Флаг -detached в команде выше - результат этого открытия. Час ушёл на диагностику, потом три минуты на правку pipeline.

Вторая загрузка прошла чисто. Портал присвоил SBOM статус «Принят», привязал его к карточке сертификата продукта и сгенерировал отчёт о составе компонентов. Этот отчёт аудитор видит в своём интерфейсе - нам его отдельно предоставлять не нужно.

Что проверял аудитор

Аудит в части SBOM оказался менее болезненным, чем мы ожидали. Проверяющий смотрел на три вещи:

• Наличие SBOM в портале для каждой версии ПО, заявленной на объекте - это проверяется автоматически по карточке сертификата.
• Актуальность - дата SBOM не должна быть старше последнего релиза продукта. Если вышел патч, должен быть SBOM для версии с патчем.
• Полнота транзитивных зависимостей - аудитор выборочно проверил несколько компонентов из SBOM и убедился, что их собственные зависимости тоже указаны.

По третьему пункту у одного из продуктов обнаружился пробел: Java-библиотека, которую Syft нашёл в JAR, но не развернул её собственное дерево зависимостей. Причина - JAR был fat JAR без исходного pom.xml рядом. Это известное ограничение Syft для упакованных Java-артефактов: он видит байткод, но не метаданные сборки. Договорились с аудитором зафиксировать это как техническое ограничение с компенсирующей мерой - ручной проверкой этой конкретной библиотеки. Не идеально, но принято.

Что сейчас не автоматизировано

Загрузка на портал ФСТЭК пока ручная. Портал предоставляет API - документация на него есть в Личном кабинете, но она написана в стиле «метод работает, подробности уточняйте». Мы потратили немного времени на реверс-инжиниринг запросов в браузере и в целом понимаем, как это автоматизировать. Пишем скрипт, который будет триггериться из CI после успешной подписи и загружать файлы сам. Для заказчиков, которые будут выпускать релизы чаще пары раз в квартал, это важно - ручная загрузка каждой версии утомляет.

Для тех, кто только начинает разбираться с SBOM под требования ФСТЭК, и хочет понять, с чего стартовать - задача хорошо укладывается в рамки аудита, где мы разбираем текущее состояние и настраиваем пайплайн под конкретный стек.