Что такое SBOM на практике
SBOM — снимок состава конкретной сборки. Таблица с библиотеками на это не тянет: она врет уже на следующем коммите. По SBOM команда должна быстро сказать, какой компонент вошел в продукт, в какой версии и в каких артефактах он сейчас лежит.
Проверяется это дважды, и оба раза внезапно. Первый раз, когда выходит громкая уязвимость: вы либо за час называете сборки, где она есть, либо неделю опрашиваете разработчиков и всё равно ошибаетесь. Второй раз на приемке, когда заказчик просит доказать, что неизвестных компонентов в продукте нет.
Отсюда правило: SBOM генерируется в конвейере сборки и хранится вместе с релизом. И сразу ловушка: хеш внутри SBOM сам по себе ничего не доказывает, файл можно перегенерировать задним числом. Связывает SBOM с артефактом подписанная аттестация (cosign, in-toto).
Вторая ловушка — идентификация компонента. Без канонического идентификатора (purl) матчинг на уязвимости не работает: «openssl 3.0.2» и «OpenSSL 3.0.2-1ubuntu1» для машины — разные строки. Дальше российская специфика: инструментарий отдает CVE, а на практике приходится учитывать еще и БДУ ФСТЭК. Сопоставление между ними есть, но неполное: часть записей сверяют руками, и время на это надо закладывать заранее.
Что изменилось в российском контуре
Здесь надо развести два разных документа 2026 года. Их постоянно путают.
Первый. ФСТЭК утвердила 12 мая 2026 года новую методику выявления уязвимостей и НДВ в ПО; информационное сообщение вышло 28 мая 2026 года под № 240/24/3693. Методика от 25 декабря 2020 года с этого момента не применяется. Публично выложена выписка — уровни контроля с шестого по четвертый; всего их шесть, первый — самый высокий. Уровень контроля задает глубину анализа; путать его с уровнем доверия из приказа № 76 не стоит.
Второй. Приказ ФСТЭК от 20 января 2026 года № 9 изменил Положение о системе сертификации СЗИ. Опубликован 21 апреля, а действует со 2 мая 2026 года. Даты разные, путать их дорого.
И то и другое работает в контуре сертификации, а не «для всего реестра отечественного ПО»: это самая частая ошибка в обсуждениях. Методика адресована испытательным лабораториям и разработчикам при сертификационных испытаниях СЗИ и защищенных программно-технических средств, а также при внесении изменений в ранее сертифицированные средства. Слов «реестр» и «Минцифры» в ней нет.
Приказ № 9 требует прикладывать к заявке на сертификацию перечень заимствованных open-source-компонентов и перечень образов контейнеров. Дальше то, что бьёт по процессу разработки, и здесь важна точность: срок установлен именно для open-source-перечня. При его изменении изготовитель обязан представить во ФСТЭК скорректированный перечень в течение пяти календарных дней, а непредставление таких сведений добавлено в основания для приостановления действия сертификата. Для перечня образов контейнеров отдельного срока и такого основания в приказе нет.
Норма написана про изменение перечня, а не про каждый коммит: где проходит граница — bump патч-версии, новая транзитивная зависимость, — приказ не разбирает, практики пока нет. Я бы сверялся с составом поданного перечня и любое расхождение считал изменением. Апдейт библиотеки был строкой в чейнджлоге, а теперь у него внешний срок.
Про формат: он больше не «на ваш вкус»
Тезис «CycloneDX или SPDX, какая разница, оба машиночитаемые» в российском контуре уже неверен. Методика задаёт CycloneDX в нотации JSON, причём в поле specVersion допускаются только значения «1.6» или «1.7». Так описываются оба перечня — и компонентов, и образов контейнеров. purl обязателен. Добавлены свои атрибуты: GOST:attack_surface, GOST:security_function, GOST:provided_by. SPDX в методике не упоминается ни разу.
Следствие чисто инженерное. Если конвейер выгружает только SPDX, к сертификации вы правите пайплайн, а не документы. Отдельная история — хеши, и требование здесь не сплошное: если источник компонента указан как архив с исходниками (source-distribution), хеши обязательны, и среди них обязан быть Стрибог (ГОСТ 34.11-2012, 256 или 512 бит по архиву исходников). Для ссылки на репозиторий (vcs) такого требования нет. Типовые генераторы Стрибога считать не умеют, так что ГОСТовые суммы придется добивать своим шагом сборки — но только там, где норма их требует.
Что требует EU Cyber Resilience Act
CRA шире процедуры сертификации. Приложение I требует выявлять и документировать компоненты и уязвимости продукта, в том числе составлять SBOM в общеупотребимом машиночитаемом формате, покрывающий как минимум зависимости верхнего уровня. Конкретный формат, в отличие от ФСТЭК, не назван: Еврокомиссия вправе задать его позже.
Сроки. Основные обязанности применяются с 11 декабря 2027 года, а уведомления об активно эксплуатируемых уязвимостях и серьезных инцидентах — уже с 11 сентября 2026 года. Ждать 2027-го опасно: историю компонентов и решений задним числом не восстановить.
И уточнение к формулировке, которая ходит по рынку. «Хранить SBOM десять лет» — упрощение. Десять лет в регламенте относятся к технической документации и декларации о соответствии: их держат в распоряжении надзорных органов не менее десяти лет после вывода продукта на рынок либо весь период поддержки, если он дольше. SBOM попадает под этот срок постольку, поскольку входит в состав техдокументации; отдельной обязанности «хранить SBOM» в регламенте нет. Это не казуистика: хранить придется всю доказательную базу вокруг файла, сам по себе он ничего не подтверждает.
Как не делать одну работу дважды
Реестр состава хранит больше, чем имя и версию компонента: purl, происхождение, лицензию, прямые и транзитивные зависимости, хеши, привязку к образу, статус поддержки, уязвимости в привязке к CVE и к БДУ ФСТЭК и решение команды по каждой значимой уязвимости. Из него собираются две выгрузки: для сертификации — перечни компонентов и образов в заданном формате, для CRA — машиночитаемый SBOM, техдокументация и история обработки уязвимостей. Данные одни, документы разные.
Где процесс ломается чаще всего
Патчи. SBOM живет ровно одну сборку. Вышел хотфикс — родился новый SBOM, а старый не перезаписывают: он доказывает состав релиза, который уже ушел заказчику. Это ближе к акту приемки, чем к заметке в блокноте: задним числом такое не переписывают.
Контейнеры. Современные сканеры умеют многое: пакеты ОС, языковые менеджеры, архивы, а некоторые заглядывают и в бинарники Go и вложенные JAR. Дело не в слепоте инструмента, а в полноте и настройке каталогизаторов: часть выключена по умолчанию, часть не покрывает то, как собран именно ваш образ. Vendored-зависимость, артефакт из приватного репозитория, файл, скопированный на промежуточном этапе multi-stage-сборки, легко не попадают в перечень. Поэтому перечень собирают на этапе сборки приложения, где известен манифест, а скан готового образа держат как перекрестную проверку, а не как единственный источник.
Ложная точность. Наличие уязвимого компонента еще не доказывает, что уязвимость эксплуатируема именно в этой сборке. Для этого есть VEX — машиночитаемая запись о применимости, а не строчка в вики. Решение «не применимо» хранится вместе с основанием: конфигурация, недостижимость кода, отключенная функция, компенсирующая мера. Через два года на переоформлении сертификата лаборатория спросит именно про этот компонент, а инженера, принявшего решение, в компании уже не будет. Останется либо запись, либо ничего.
Если у команды нет реестра активов и истории уязвимостей, начинать надо с учета, а не с генерации SBOM. Иначе документ соберут. Подтверждать им будет нечего.
Сегодня SBOM перестал быть формальным приложением к релизу — он становится частью процесса разработки и сопровождения программного продукта. Чем раньше команда встроит его генерацию и сопровождение в CI/CD и начнет вести единый реестр компонентов, тем проще будет учитывать требования ФСТЭК и CRA, быстрее реагировать на новые уязвимости и избежать лишней ручной работы. Главный принцип здесь прост: поддерживать нужно не несколько разных SBOM, а один достоверный источник данных, из которого формируются все необходимые документы.
