Блог CodeScoring

Упрощение работы с перечнем программных компонентов (ППК) по требованиям ФСТЭК с помощью CodeScoring

В 2024 году ФСТЭК России в информационном письме “О порядке взаимодействия с центром исследований безопасности системного программного обеспечения" определила порядок взаимодействия участников сертификации с Центром исследований безопасности системного программного обеспечения, созданным на базе ИСП РАН, включая Требования к представлению перечней заимствованных компонентов с открытым исходным кодом.

В конце 2025 года ФСТЭК также опубликовала проект приказа о внесении изменений в систему сертификации средств защиты информации, который выносит Требования на нормативный уровень. Проект предполагает обязательное включение в материалы на сертификацию перечней open source компонентов и образов контейнеров, а также их поддержание в актуальном состоянии. В случае принятия документа изготовители СЗИ будут обязаны предоставлять такие перечни в табличной и машиночитаемой формах, а несоблюдение Требований может повлиять на статус сертификата.

Перечень в машиночитаемом формате строго регламентирован приложением №3 к Требованиям: обязательно использование CycloneDX не ниже версии 1.6, наличие метаданных с описанием продукта, массив компонентов с обязательными полями type, name, version, externalReferences, properties (обязательно с дополнительными свойствами, перечисленными ниже), а также ссылка на репозиторий с исходным кодом компонента или ссылка на архив с исходным кодом и список хэшей. Дополнительно допускаются другие поля CycloneDX.

От классического SBOM, описанного в спецификациях CycloneDX и SPDX, российская практика отличается введением дополнительных свойств, которые расширяют стандартные форматы без нарушения их структуры. Эти свойства размещаются в разделе properties компонентов и помогают категоризировать элементы по следующим критериям:

  • GOST:attack surface – указывает, относится ли компонент к поверхности атаки. Возможные значения: «yes», «indirect», «no». Поле позволяет оценить, насколько компонент может быть точкой входа для атак, и приоритизировать анализ рисков.
  • GOST:security_function – определяет, реализует ли компонент функции безопасности. Значения: «yes», «indirect», «no». Это помогает выделить элементы, которые напрямую влияют на защиту информации, и понять, какие части ПО требуют повышенного контроля.
  • GOST:provided_by — содержит название СЗИ, из которого заимствован компонент. Заполняется только для случаев наследования из уже сертифицированных продуктов, что упрощает трассировку цепочки доверия и частично наследует результаты предыдущих проверок.
  • GOST:source_langs — список языков исходного кода компонента. Полезно для оценки происхождения и применимости инструментов статического анализа.

Эти поля не заменяют базовые атрибуты (name, version, purl, hashes, licenses, supplier), а дополняют их, делая SBOM более информативным для экспертизы. Их наличие позволяет быстрее проходить валидацию в инструментах, используемых при сертификации, и снижает количество замечаний от экспертов.

Для проверки корректности перечня можно применять инструмент SBOM Checker от ИСП РАН. Он валидирует структуру, обязательные поля и наличие дополнительных свойств. Инструмент ориентирован на проверку, а не на генерацию перечня.

CodeScoring поддержал формирование ППК (SBOM) согласно требованиям регулятора с указанием необходимых параметров в специальных форматах CycloneDX 1.6 Ext и 1.7 Ext. Расширенные версии CycloneDX позволяют включить требуемые свойства как дополнительные поля в properties, сохраняя полную совместимость со спецификацией и порядком ФСТЭК.

Не все поля заполняются автоматически: GOST:attack_surface и GOST:security_function требуют экспертной оценки архитектуры и роли компонента в СЗИ, GOST:provided_by – знания о заимствованиях из других продуктов. В CodeScoring эти значения задаются вручную в интерфейсе проекта – в таблице зависимостей для каждого компонента. Указанные свойства сохраняются в профиле проекта и автоматически применяются при последующих выгрузках перечня компонентов.
Особое внимание уделяется сбору ссылок на исходные коды. Поля секции externalReferences заполняются автоматически с указанием URL репозиториев при обнаружении и могут быть отредактированы вручную. Для повышения качества ссылки проверяются, корректируются и дополняются для всех поддерживаемых экосистем. Это кратно ускоряет подготовку перечня для центра: эксперт или проверяющий может сразу перейти к исходникам и провести анализ в соответствии с методиками центра. В условиях детальных требований к происхождению и верификации зависимостей такой подход существенно сокращает время на доработку материалов и замечания от органа по сертификации.

Экспорт перечня осуществляется из интерфейса проекта кнопкой «Скачать SBOM». Выбирается формат (в т.ч. CycloneDX v1.6 Ext JSON с GOST-полями), файл генерируется с учетом всех настроек.
Подробнее о процессе экспорта и настройке свойств описано в документации платформы.

В итоге CodeScoring позволяет сформировать перечень заимствованных компонентов в полном соответствии с порядком ФСТЭК и Требованиями Центра. Автоматический сбор базовых атрибутов сочетается с удобным механизмом настройки дополнительных свойств, что делает подготовку материалов к сертификации более структурированной и менее подверженной ошибкам.
Получить демо