Поставщик СЗИ прислал вместе с обновлением файл на сорок тысяч строк в формате CycloneDX. В сопроводительном письме одна фраза: «Перечень программных компонентов по методике ФСТЭК». Что с ним делать, в письме не сказано. Так SBOM приходит к заказчику: вложением без инструкции, за которое теперь отвечает получатель.
Эта статья для организации, которая покупает и эксплуатирует ПО: госорган с ГИС, субъект КИИ, оператор ПДн, банк. Не для разработчика. Разберём, что такое SBOM, почему с 2026 года его начали присылать, что приказы ФСТЭК №117 и №239 требуют от вас про состав ПО и какие четыре шага превращают файл поставщика в закрытые уязвимости.
Что такое SBOM простыми словами
SBOM (Software Bill of Materials) означает состав программного продукта: список компонентов, из которых он собран, с версиями, лицензиями и идентификаторами. Аналогия с составом на упаковке точная. Производитель йогурта обязан перечислить ингредиенты, производитель ПО перечисляет библиотеки, фреймворки, образы контейнеров и их версии.
Разница с «списком установленного ПО», который снимает агент инвентаризации, принципиальная. Инвентаризация видит продукт целиком: «КриптоПро CSP 5.0», «Kaspersky Endpoint Security 12». SBOM смотрит внутрь продукта: библиотека OpenSSL 3.0.13, парсер libxml2 2.12.6, среда выполнения .NET 8.0.4. Уязвимость живёт именно на этом уровне. Когда выходит критическая уязвимость в OpenSSL, вопрос «в каких наших продуктах она есть» без SBOM решается опросом поставщиков и занимает недели.
Три свойства отличают рабочий SBOM от декоративного:
- Привязка к сборке. SBOM описывает конкретную версию продукта. Вышел патч, родился новый SBOM. Старый не переписывают: он подтверждает состав релиза, который уже стоит у вас.
- Машиночитаемый формат. Excel с названиями библиотек не сопоставить с базой уязвимостей автоматически. Нужен формат с идентификаторами компонентов, по которым программа находит запись в БДУ или CVE.
- Канонический идентификатор компонента. В формате CycloneDX это purl (package URL). Без него «openssl 3.0.2» и «OpenSSL 3.0.2-1ubuntu1» для машины разные строки, и сопоставление превращается в ручной труд.
Как читать SBOM: что смотреть в файле
Файл CycloneDX в нотации JSON открывается любым текстовым редактором. Заказчику нужны пять полей.
metadata.timestampиmetadata.component. Когда собран файл и к какой версии продукта относится. Если дата старше даты релиза, файл не про эту версию.components. Сам перечень. У каждого компонента естьname,versionиpurl. Компонент безpurlавтоматически сопоставить не получится: его придётся искать в БДУ руками.dependencies. Граф зависимостей. По нему видно, что тянет за собой уязвимая библиотека и какие компоненты транзитивные.hashes. Контрольные суммы. По выписке из методики для компонентов, полученных из архивов исходников, хеши обязательны, в том числе по ГОСТ Р 34.11-2012.vulnerabilities. Необязательный блок: поставщик может вложить записи VEX о применимости известных уязвимостей прямо в SBOM.
Читать сорок тысяч строк глазами не нужно. Хватит выгрузить name, version и purl в таблицу и дальше работать со списком. Пример такой таблицы приложен к статье.
Почему SBOM пришёл к заказчику: методика ФСТЭК 12.05.2026 и приказ №9
До 2026 года SBOM в России обсуждали разработчики и испытательные лаборатории. Два документа перевели тему в плоскость поставок.
Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении утверждена ФСТЭК России 12 мая 2026 года, информационное сообщение вышло 28 мая 2026 года. Она пришла на смену методике от 25 декабря 2020 года, которая с этого момента не применяется. Новая методика опубликована в виде выписки и приведена в соответствие с ГОСТ Р 56939-2024 по безопасной разработке. Ключевое для заказчика: методика обязывает представлять перечни программных компонентов и образов контейнеров в машиночитаемом формате CycloneDX. Спор «CycloneDX или SPDX» в российском контуре закрыт: формат задан, идентификатор purl обязателен, в выписке указаны версии спецификации 1.6 и 1.7 и собственные атрибуты ГОСТ.
Приказ ФСТЭК России от 20 января 2026 года №9 изменил Положение о сертификации средств защиты информации (приказ №55 от 03.04.2018). Опубликован 21 апреля, действует со 2 мая 2026 года. К заявке на сертификацию теперь прилагаются перечень заимствованных программных компонентов с открытым исходным кодом и перечень образов контейнеров в составе средства защиты. При изменении перечня открытых компонентов изготовитель представляет во ФСТЭК скорректированный перечень в течение пяти календарных дней, а непредставление таких сведений стало основанием для приостановления действия сертификата.
Область действия обоих документов важно не расширять. Методика и приказ №9 работают в контуре сертификации СЗИ и защищённого ПО. Слов «реестр отечественного ПО» и «Минцифры» в методике нет. Обязанность составлять SBOM лежит на изготовителе, который сертифицирует продукт.
Что из этого следует заказчику. Для каждого СЗИ, заявка на сертификацию или материалы испытаний по изменениям которого поданы во ФСТЭК после 2 мая 2026 года, у изготовителя есть перечень заимствованных открытых компонентов и перечень образов контейнеров (если такие компоненты в продукте есть), а при испытаниях по методике от 12.05.2026 они готовятся в CycloneDX. У поставщика этот файл уже есть. Просить его можно и нужно, а дальше он становится вашей ответственностью: уязвимости в компонентах надо находить и устранять вам, в вашей инфраструктуре, в сроки, которые задают ваши приказы.
Что приказы №117 и №239 требуют от вас про состав ПО
Ни один приказ ФСТЭК не содержит слова «SBOM». Обязанности сформулированы иначе, и именно поэтому состав ПО становится вашей проблемой.
Приказ №117 (требования к защите информации в ГИС и иных системах госорганов, действует с 1 марта 2026 года) устанавливает сроки устранения уязвимостей по уровню критичности: критические в течение 24 часов, высокие в течение 7 дней (п. 38). Уровень критичности считается по методике ФСТЭК от 30.06.2025: базовая оценка CVSS умножается на показатель влияния на инфраструктуру. Чтобы посчитать показатель влияния, нужно знать, на каком узле стоит уязвимый компонент и доступен ли узел из интернета. То есть нужна связка «компонент → продукт → актив». SBOM даёт первое звено, реестр активов второе. Разбор приказа в статье «Приказ ФСТЭК №117: требования и автоматизация».
Приказ №239 (значимые объекты КИИ) включает анализ уязвимостей и их устранение в базовый набор мер для всех категорий (АУД.2) и требует его в ходе эксплуатации (п. 13.2) с периодичностью, которую субъект КИИ устанавливает сам. Для субъекта КИИ поставляемое ПО, включая сертифицированные СЗИ, входит в периметр анализа. Сканер найдёт уязвимость в OpenSSL внутри СЗИ, только если знает, что OpenSSL там есть: перечень компонентов даёт эту информацию раньше сканера.
Приказ №21 для операторов ПДн содержит аналогичную группу мер анализа уязвимостей. Логика та же: уязвимости в компонентах ПО, обрабатывающего ПДн, находятся и устраняются оператором.
Есть и второй мост, уже в самом приказе №117: он отсылает к ГОСТ Р 56939-2024 по безопасной разработке для организаций, которые пишут собственное ПО. Мы разбирали стандарт в статье «РБПО по ГОСТ Р 56939». В этой картине SBOM служит выходным артефактом безопасной разработки поставщика и входным артефактом управления уязвимостями заказчика.
Что делать с полученным SBOM: четыре шага
Шаг 1. Положить в реестр активов, привязав к системе
SBOM без привязки к активу бесполезен: он говорит, что входит в сборку, но не говорит, где сборка стоит. Первое действие: записать продукт, версия, SBOM (файл и его хеш), дата получения, системы и узлы, где этот продукт установлен, владелец системы. Если у вас есть реестр ИТ-активов, это одна запись с вложением. Если реестра нет, дальше идти рано, об этом ниже.
Отдельно зафиксируйте, к какой именно версии относится файл. Поставщик, который присылает один SBOM «на продукт», а не на каждую версию, присылает документ, который врёт после первого патча.
Шаг 2. Сопоставить компоненты с БДУ ФСТЭК и CVE
Компоненты из SBOM ищутся в двух базах. БДУ ФСТЭК здесь регуляторный источник: именно на записи БДУ вы будете ссылаться в отчётах контроля защищённости и при проверках. Идентификатор CVE проставлен у 96,9% записей БДУ (по нашей сверке XML-выгрузки банка на август 2026 года: 89 183 из 92 045 записей), так что сопоставление через CVE работает почти всегда. Обратная задача сложнее: справочник ПО в БДУ (bducpe) не содержит версий, поэтому по нему определить «уязвима ли именно ваша версия» нельзя. Версию берут из SBOM, диапазон уязвимых версий из записи БДУ или CVE.
Инструменты композиционного анализа (SCA) делают это сопоставление автоматически: читают SBOM или сканируют артефакт, ищут компоненты в базах уязвимостей и отдают список находок с версиями, в которых уязвимость исправлена. Для заказчика в России у них два ограничения, и оба серьёзные. Базы. Кириллица. Большинство сканеров знают CVE и не знают БДУ, а российские продукты и дистрибутивы в их словарях отсутствуют: в открытых матчерах, которые мы разбирали, нет ни одной российской ОС. Находки по сертифицированным СЗИ и отечественному ПО придётся сверять с БДУ отдельно.
Практический приём: сопоставлять по purl и CVE, а не по названию. Названия в разных источниках расходятся: «Битрикс24» и «Bitrix24», «РЕД ОС» и «redos». Для российского ПО с кириллическими именами совпадений по названию почти нет: это видно на выгрузке БДУ и каталоге bducpe.
Шаг 3. Завести задачи на уязвимые компоненты со сроками по критичности
Найденная уязвимость без ответственного и срока остаётся строкой в отчёте. Для каждой: оценка критичности по методике (V = Icvss × Iinfr), срок по приказу, ответственный, решение. Решений три: обновить продукт (запросить у поставщика версию с исправлением), применить компенсирующую меру (закрыть порт, отключить функцию, ограничить доступ), зафиксировать неприменимость с обоснованием. Третий вариант нужен часто: уязвимый компонент может лежать в продукте, но не использоваться в вашей конфигурации. Обоснование хранится рядом с решением, потому что через год его спросит проверяющий, а инженера, который решал, в компании может уже не быть.
🧾 Уязвимости из SBOM в общем реестре В КиберОснова продукты ПО привязываются к активам и ответственным в реестре активов, уязвимости сопоставляются с БДУ ФСТЭК, а задачи на устранение получают сроки по приказу №117 (для КИИ — по внутреннему регламенту) и ответственных в модуле «Задачи ИБ». SBOM платформа не генерирует: она связывает состав ПО, который прислал поставщик, с тем, что у вас реально установлено.
Пример: одна уязвимость, два актива
Поставщик прислал SBOM для СЗИ версии 5.2.1. В нём OpenSSL 3.0.13. По CVE в БДУ находится запись с базовой оценкой 8,5. СЗИ стоит на двух узлах. Первый: сервер приложений ГИС, доступный из интернета. Показатель влияния 0,82, V = 6,97, уровень высокий, срок устранения 7 дней. Второй: рабочее место бухгалтера в изолированном сегменте. Показатель 0,50, V = 4,25, уровень средний, срок до четырёх недель. Один компонент, одна запись БДУ, два разных срока. Срок считается от актива, а не от файла. Без реестра активов оба случая выглядели бы одинаково.
Шаг 4. Повторять при каждом обновлении
Обновление продукта меняет состав. Новый релиз означает новый SBOM, новое сопоставление, новые задачи. Если поставщик сертифицированного СЗИ не присылает перечень с патчем, спрашивайте: перечень открытых компонентов по приказу №9 он обновляет во ФСТЭК в пятидневный срок, значит, актуальная версия существует. Раз в квартал стоит сверять список продуктов в реестре активов с наличием SBOM: пробелы покажут, у кого запрашивать.
Что это даёт на проверке
На проверке ФСТЭК или при контроле уровня защищённости спрашивают результат: какие уязвимости найдены, что с ними сделано и когда. Сам файл SBOM никого не интересует. С 1 сентября 2026 года отчёт (протокол) контроля защищённости аттестованного объекта включает порядок и результаты анализа уязвимостей (п. 31² Порядка аттестации в редакции приказа ФСТЭК № 60). Связка «компонент → актив → уязвимость → решение → срок» и есть этот отчёт, только собранный заранее, а не за неделю до проверки.
Подводные камни
SBOM живёт одну сборку. Самая частая ошибка: хранить один «актуальный» SBOM на продукт и перезаписывать его. Старые версии нужны: они доказывают состав того, что стояло у вас в момент инцидента или проверки.
Контейнеры. Сканер образа видит пакеты ОС и языковые зависимости, но легко пропускает то, что скопировано в образ на промежуточном этапе сборки: артефакт из приватного репозитория, vendored-зависимость. Перечень образов контейнеров, который методика требует отдельно, закрывает эту дыру только если составлен на стороне сборки, а не по результату скана готового образа. Заказчику проверить это трудно, поэтому в требованиях к поставщику фиксируют, что перечень составлен из манифеста сборки.
Ложная точность. Наличие уязвимого компонента не означает, что уязвимость эксплуатируема в вашей сборке. Для этого существует VEX (Vulnerability Exploitability eXchange): машиночитаемая запись о применимости. Если поставщик присылает VEX вместе с SBOM, часть задач закрывается его обоснованием. Если не присылает, обоснование неприменимости придётся писать вам или требовать у него.
Формальный SBOM «к аудиту». Файл, собранный один раз для сертификации и не обновлявшийся, хуже отсутствия файла: он создаёт иллюзию контроля. Признак формального SBOM: дата в метаданных старше последнего обновления продукта.
Разные базы дают разные сроки. CVSS от вендора, оценка в БДУ и ваш расчёт по методике могут расходиться. Приказ №117 требует оценивать уязвимости по методическим документам ФСТЭК (п. 68, для сроков п. 38 — по ГОСТ Р 56545-2015), значит, срок устранения считается по методике, а не по бейджу критичности из SBOM-сканера.
📊 Сколько уязвимостей у вас в поставляемом ПО Список продуктов из реестра активов можно прогнать по реестру БДУ ФСТЭК: поиск по названию ПО, году и критичности по полной выгрузке банка (92 045 записей на август 2026 года). Это первая оценка до того, как поставщики пришлют SBOM.
Чего требовать от поставщика
Требования к SBOM удобно закрепить в договоре или техническом задании, иначе каждый поставщик пришлёт что-то своё: один в PDF, другой в Excel, третий ссылкой на страницу, которая через месяц перестанет открываться. Список короткий. Восемь пунктов:
- Формат. CycloneDX в нотации JSON, тот же, что задан методикой ФСТЭК. Для сертифицированных СЗИ это бесплатно: файл уже подготовлен для ФСТЭК.
- Идентификаторы. purl у каждого компонента. Без него автоматическое сопоставление с базами уязвимостей не работает.
- Привязка к версии. SBOM на каждую поставляемую версию, с хешем артефакта, к которому он относится.
- Глубина. Прямые и транзитивные зависимости, а не только верхний уровень.
- Образы контейнеров. Отдельный перечень, составленный из манифеста сборки.
- Обновление. Новый SBOM с каждым обновлением продукта, включая хотфиксы.
- VEX. Записи о применимости для известных уязвимостей компонентов в конфигурации по умолчанию.
- Срок реакции. Обязательство сообщать о критических уязвимостях в компонентах и сроки выпуска исправления, согласованные со сроками ваших приказов (24 часа и 7 дней по №117).
Поставщик СЗИ, сертифицированного или изменённого после 2 мая 2026 года, отказываясь дать перечни компонентов и образов, отказывает в документе, который он уже представил во ФСТЭК по приказу №9. Это аргумент в переговорах. Для несертифицированного ПО прямой обязанности нет, и здесь работает только договор.
Отдельный вопрос: уровень доверия СЗИ по приказу ФСТЭК №76: шесть уровней, первый самый высокий. Чем выше уровень доверия, тем глубже испытания и тем полнее проектная, тестовая и эксплуатационная документация. Как выбрать уровень под свою систему, разобрано в статье «Уровни доверия ФСТЭК».
Если реестра ИТ-активов нет, начинать надо с него
SBOM отвечает на вопрос «что входит в сборку». Инвентаризация отвечает на вопрос «где и на каких активах эта сборка стоит». Реестр уязвимостей отвечает на вопрос «что из этого требует реакции». Без первого звена цепочки SBOM некуда положить, без второго его не с чем сопоставить.
Типичная картина у организации, которая начинает с SBOM: файлы поставщиков собраны в папку, сопоставление сделано один раз вручную, через квартал никто не знает, какие из них актуальны. Причина в отсутствии учёта: неизвестно, какое ПО и каких версий реально установлено на узлах.
Порядок, который работает: сначала учёт установленного ПО агентом, с версиями и привязкой к узлам; затем реестр продуктов с поставщиками и владельцами; затем SBOM как вложение к продукту; затем сопоставление и задачи. Первые два шага дают результат сами по себе, ещё до того, как поставщики пришлют хоть один файл: сканеры уязвимостей и сверка с БДУ по установленному ПО находят большую часть того, что позже подтвердит SBOM.
📥 Шаблон связки для старта Таблица, в которой SBOM, версия продукта, ИТ-актив, уязвимость, решение и ответственный лежат в одной строке. Подходит для первых десяти продуктов, пока реестр не переехал в систему. Скачать шаблон можно ниже, а проверить, какое ПО реально установлено в вашей инфраструктуре, на странице учёта программного обеспечения.
Коротко
SBOM: состав программного продукта в машиночитаемом формате, который поставщик готовит для сертификации, а заказчик использует, чтобы найти уязвимые компоненты в купленном ПО раньше, чем их найдёт злоумышленник или проверяющий. С 2026 года изготовители СЗИ при сертификации и изменениях представляют во ФСТЭК перечни открытых компонентов и образов контейнеров (приказ №9), а при испытаниях по методике от 12.05.2026 — в формате CycloneDX. Для заказчика это источник данных об уязвимостях в поставляемом ПО, а обязанность их устранять уже лежит на нём по приказам №117, №239 и №21. Четыре шага: реестр активов, сопоставление с БДУ и CVE, задачи со сроками по критичности, повтор при каждом обновлении. Начинать с учёта установленного ПО, требовать SBOM договором, хранить версии и обоснования решений.
