ФСТЭК России утвердила новую методику выявления уязвимостей в ПО: акцент на ГОСТ Р 56939-2024 и современные форматы SBOM

ФСТЭК России утвердила новый методический документ «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении» от 12 мая 2026 года. Документ призван актуализировать подходы к сертификации средств защиты информации (СЗИ) и безопасного ПО в условиях развития современных практик разработки.

Что заменяет документ

Нововведения приходят на смену закрытой методике от 25 декабря 2020 года. Предыдущий документ имел гриф «Для служебного пользования», не публиковался в открытых источниках и был доступен узкому кругу аккредитованных лабораторий.

Актуальный документ, помимо обновления устаревших технических подходов, предоставляет правила оценки уязвимостей на обозрение заинтересованных лиц, делая их публичными и детализированными.

Суть ключевых изменений

Новая методика представляет собой значительное усложнение и детализацию требований к испытательным лабораториям и разработчикам.
Основные изменения включают:

1. Привязка к новым стандартам: Методика полностью синхронизирована с требованиями ГОСТ Р 56939-2024 и Приказом ФСТЭК № 76 от 2020 года. Все виды исследований (анализ архитектуры, статический и динамический анализ, фаззинг, экспертиза кода) теперь жестко привязаны к 6-ти уровням доверия (где 1 – самый высокий, 6 – самый низкий).
2. Учет современных технологий разработки: В документ официально введены требования к проверке сред контейнеризации (средства контейнерного исполнения) и виртуализации, анализу сборочных сред, а также к использованию специализированных фаззеров для динамического анализа.
3. Внедрение стандартов перечней программных компонентов: Методика обязывает представлять перечни программных компонентов (SBOM, Software Bill Of Materials, в грубом переводе «сводка программных материалов») и образов контейнеров в машиночитаемом формате CycloneDX. Речь идёт в том числе об обязательном указании хеш-сумм (включая отечественные алгоритмы Streebog), ссылок на репозитории и свойств объекта, относящих его к поверхности атаки (GOST:attack_surface), функциям безопасности (GOST:security_function), а также заявляющих о заимствовании из сертифицированных СЗИ (GOST:provided_by). Подробнее описано в таблицах Приложения 1.
4. Оптимизация повторных проверок: Введен механизм, позволяющий испытательной лаборатории повторно использовать результаты статического или динамического анализа, проведенного самим разработчиком в соответствии с ГОСТ Р 56939-2024. Если доля неверно размеченных разработчиком ложных срабатываний в контрольной выборке не превышает 10%, лаборатория может воспользоваться результатами разработчика. В противном случае лаборатория проводит анализ самостоятельно или выносит решение о невозможности проведения дальнейших исследований.

Потенциал новой методики

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

1. Для рынка: Внедрение обязательного формата SBOM и четких критериев приемки результатов разработчика прозрачные правила прохождений сертификаций и оценок. Это позволит компаниям, внедрившим практики ГОСТ Р 56939-2024 и DevSecOps, существенно ускорить и удешевить процесс сертификации за счет переиспользования результатов тестов и заранее подготовленного под новые стандарты плана действий.
2. Для безопасности: Детализация требований к фаззинг-тестированию, анализу скрытых каналов и проверке заимствованных компонентов, включая анализ цепочек поставок, направлена на реальное повышение устойчивости функционирования информационных систем.