Сертифицированное средство защиты может делать то, чего нет в его документации. Отладочный интерфейс, который забыли отключить. Библиотека с открытым кодом, в которой три года живёт бэкдор. Скрытая команда, оставленная подрядчиком «на всякий случай». Всё это называется недекларированными возможностями, и с 2026 года ФСТЭК проверяет их по новым правилам: приказ №9 от 20 января изменил порядок сертификации, а методика от 12 мая задала, как искать такие возможности и в каком виде описывать состав продукта.
Статья для двух читателей. Изготовителю СЗИ она объясняет, что теперь прикладывать к заявке и чем грозит забытый перечень компонентов. Заказчику, который покупает и эксплуатирует сертифицированные средства в ГИС, на объектах КИИ и в ИСПДн, она показывает, что спросить у поставщика и как связать контроль НДВ с учётом уязвимостей в своей инфраструктуре.
Что такое недекларированные возможности простыми словами
Определение из методических рекомендаций ФСБ (№ 149/54-144) обобщает руководящий документ Гостехкомиссии 1999 года: недекларированные возможности программного обеспечения означают функциональные возможности, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение характеристик безопасности защищаемой информации.
Ключевое слово здесь «функциональные». Уязвимость появляется из ошибки: переполнение буфера, некорректная проверка входных данных, устаревшая криптография. Недекларированная возможность появляется из умысла или небрежности: код делает ровно то, что задумал его автор, просто об этом не сказано в формуляре. Отсюда разные способы поиска. Уязвимости ищут сканером по базам известных дефектов. Недекларированные возможности ищут анализом кода, состава компонентов и поведения программы, потому что в базах их нет.
Откуда они берутся на практике:
- Закладки. Намеренно встроенный код: скрытая учётная запись, команда обхода аутентификации, канал передачи данных наружу.
- Отладочные и служебные функции. Интерфейсы для разработчиков, тестовые режимы, расширенное логирование, которые не отключили в релизе.
- Заимствованные компоненты. Библиотека с открытым кодом или образ контейнера с функциональностью, о которой изготовитель СЗИ сам не знал. Именно этот источник приказ №9 вывел в отдельный контур контроля.
- Расхождение с документацией. Функция описана одним образом, реализована другим. Формально это тоже НДВ, даже без злого умысла.
Для оператора персональных данных недекларированные возможности имеют прямое юридическое измерение. По постановлению Правительства №1119 угрозы 1-го типа связаны с наличием НДВ в системном ПО, угрозы 2-го типа с НДВ в прикладном. Признание таких угроз актуальными поднимает уровень защищённости ИСПДн и требования к средствам защиты. Как определяется уровень, разобрано в статье «Уровни защищённости ПДн по ПП 1119».
Приказ ФСТЭК №9 от 20.01.2026: что изменилось в сертификации
Приказ №9 вносит изменения в Положение о системе сертификации средств защиты информации (приказ ФСТЭК №55 от 03.04.2018). Опубликован 21 апреля 2026 года, вступил в силу 2 мая 2026 года. Даты стоит различать: с 21 апреля по 2 мая приказ существовал, но не действовал.
Четыре изменения, которые меняют работу изготовителя и косвенно заказчика.
Перечни компонентов в заявке. К заявке на сертификацию и к образцу, передаваемому в испытательную лабораторию, теперь прилагаются перечень заимствованных программных компонентов с открытым исходным кодом и перечень образов контейнеров, входящих в состав средства защиты. Оба перечня подаются при наличии таких компонентов в продукте. До приказа №9 состав заимствованного кода в заявке не фиксировался.
Срок обновления перечня. Новый пункт 73¹ Положения: при изменении перечня открытых компонентов изготовитель в течение 5 календарных дней со дня изменения представляет во ФСТЭК скорректированный перечень. Для образов контейнеров отдельного срока приказ не установил.
Новое основание для приостановления сертификата. Пункт 83 Положения в редакции приказа №9 добавил к основаниям приостановления непредставление сведений об изменениях в перечне заимствованных открытых компонентов. Остальные основания сохранились: изменение требований по безопасности, установленное несоответствие продукта требованиям, в том числе наличие в нём уязвимостей или недекларированных возможностей, прекращение технической поддержки, обращение самого заявителя.
Последствия приостановления. По пункту 84 действие сертификата приостанавливается на срок до 90 календарных дней, в уведомлении ФСТЭК указывает срок устранения несоответствия. По пункту 85 на время приостановления заявитель прекращает производство и реализацию средства защиты. Для изготовителя это остановка продаж, для заказчика с уже купленным продуктом это вопрос к поставщику о сроках исправления.
Стоит помнить и о базовой обязанности, которая в Положении была и раньше: заявитель (как правило, он же изготовитель) по пункту 11 Положения отвечает за техническую поддержку сертифицированного средства, и в неё входит устранение уязвимостей и недекларированных возможностей, информирование потребителей об обновлениях и доведение до них обновлений и изменений в эксплуатационную документацию. Прекращение такой поддержки само по себе основание для приостановления сертификата.
📋 Проверьте сертификат перед покупкой Номер сертификата, схема сертификации и класс защиты видны в реестре сертифицированных СЗИ ФСТЭК на нашем сайте: поиск по названию и номеру, карточка сертификата, а для популярных продуктов — связанные записи БДУ.
Методика выявления уязвимостей и НДВ от 12.05.2026
Приказ №9 задал, что подавать. Методика задала, как проверять. Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении утверждена ФСТЭК России 12 мая 2026 года, информационное сообщение об этом вышло 28 мая 2026 года. Она пришла на смену методике от 25 декабря 2020 года, которая с этого момента не применяется, и приведена в соответствие с ГОСТ Р 56939-2024 по безопасной разработке.
Три вещи, которые важно знать о новой методике.
Она опубликована в виде выписки. Прежняя методика 2020 года была закрытым документом. Новая доступна публично, но не целиком: в выписке описаны уровни контроля с шестого по четвёртый. Всего уровней шесть, первый самый высокий. Уровень контроля задаёт глубину анализа: чем выше требуемый уровень, тем больше видов проверок и тем глубже они идут в код и состав.
Она задаёт формат описания состава. Перечни программных компонентов и образов контейнеров представляются в машиночитаемом формате CycloneDX с обязательным идентификатором компонента purl. Это тот самый SBOM, о котором заказчикам стоит прочитать отдельно: «SBOM: что заказчику делать с составом продукта». Для изготовителя следствие простое: перечень «в Excel» лабораторию не устроит, конвейер сборки должен выдавать состав в заданном формате.
Её область: сертификация. Методика адресована испытательным лабораториям и изготовителям при сертификационных испытаниях СЗИ и защищённого ПО, а также при внесении изменений в ранее сертифицированные средства. Слов «реестр отечественного ПО» и «Минцифры» в ней нет. Распространять её требования на любое российское ПО без отдельного основания неверно.
Уровень контроля отсутствия НДВ по методике и уровень доверия по приказу ФСТЭК №76 путать нельзя. Уровень доверия характеризует средство защиты целиком и тоже имеет шесть ступеней с первой как высшей, но охватывает проектирование, тестирование, поддержку и документацию. Контроль НДВ входит в эту оценку: по требования приказа №76 средство N уровня доверия проходит испытания по N уровню контроля отсутствия недекларированных возможностей. Как уровни доверия соотносятся с классами систем, разобрано в статье «Уровни доверия ФСТЭК».
Какой уровень нужен вашей системе
Требования к средствам защиты формулируются в приказах ФСТЭК через класс или категорию системы. Таблица собирает действующие нормы.
| Система | Норма | Требование к сертифицированным СЗИ |
|---|---|---|
| ГИС и иные системы госорганов 1 класса | приказ №117, п. 72 | не ниже 4 класса защиты и уровня доверия |
| ГИС 2 класса | приказ №117 | не ниже 5 класса защиты и уровня доверия |
| ГИС 3 класса | приказ №117 | 6 класс защиты и уровень доверия |
| Значимый объект КИИ 1 категории | приказ №239, п. 29 | уровень доверия 4 или выше |
| Значимый объект КИИ 2 категории | приказ №239, п. 29 | уровень доверия 5 или выше |
| Значимый объект КИИ 3 категории | приказ №239, п. 29 | уровень доверия 6 или выше |
| ИСПДн 1 уровня защищённости | приказ №21, п. 12 | не ниже 4 класса и 4 уровня доверия |
| ИСПДн 2 уровня защищённости | приказ №21, п. 12 | не ниже 5 класса и 5 уровня доверия |
| ИСПДн 3 и 4 уровня защищённости | приказ №21, п. 12 | 6 класс и 6 уровень доверия |
Две детали. Приказ №21 в 2017 году требовал для ИСПДн с актуальными угрозами 1-го и 2-го типов средства защиты, прошедшие проверку не ниже чем по 4 уровню контроля отсутствия НДВ, но приказ ФСТЭК №68 от 14.05.2020 исключил эту норму с 1 января 2021 года: теперь и для ИСПДн действует логика класса защиты и уровня доверия по уровню защищённости. Дополнительная мера для угроз 1-го и 2-го типов сохранилась в пункте 11: проверка системного и прикладного ПО, включая программный код, на отсутствие недекларированных возможностей, с автоматизированными средствами или без них. Сам уровень контроля никуда не исчез: по требования приказа №76 средство N уровня доверия проходит испытания по N уровню контроля отсутствия НДВ, то есть контроль НДВ входит в уровень доверия. Приказ №117, пришедший на смену №17 с 1 марта 2026 года, формулирует требование так же. Для заказчика это означает, что при выборе СЗИ под класс или уровень системы достаточно смотреть на класс защиты и уровень доверия в сертификате, а уровень контроля запрашивать справочно.
Кого касается приказ №9 и методика
Изготовители СЗИ и защищённого ПО. Прямые адресаты. Перечни компонентов и образов, формат CycloneDX, пятидневный срок на обновление перечня, новое основание для приостановления сертификата.
Испытательные лаборатории и органы по сертификации. Проверяют по методике, принимают перечни, фиксируют уровень контроля.
Заказчики в ГИС, на объектах КИИ, в ИСПДн. Косвенно, но ощутимо. Во-первых, у продукта, прошедшего сертификацию или изменения после 2 мая 2026 года, есть перечни открытых компонентов и образов контейнеров, если такие компоненты в нём есть, и их можно запросить. Во-вторых, приостановление сертификата поставщика становится вашим риском: пока сертификат приостановлен, ссылаться на него как на подтверждение соответствия нельзя, а узнаёте вы об этом не всегда вовремя. В-третьих, обязанность устранять уязвимости и НДВ лежит на заявителе, но обязанность устранять уязвимости в своей системе в сроки по приказу №117 лежит на вас.
Кого не касается. Разработчиков ПО, которое не сертифицируется во ФСТЭК и не претендует на статус защищённого. Требования методики не распространяются автоматически на весь реестр отечественного ПО.
Как выявляют недекларированные возможности на практике
Конкретный набор проверок зависит от уровня контроля, и полный текст методики для верхних уровней не опубликован. Общая логика видна из выписки и из ГОСТ Р 56939-2024, с которым методика согласована; ниже типовая последовательность, а точный состав проверок для верхних уровней в открытом доступе отсутствует.
Анализ состава. Первый шаг: понять, из чего собран продукт: собственный код, заимствованные компоненты, образы контейнеров, их версии и происхождение. Без этого невозможно ни оценить поверхность, ни проверить, что в сборке нет лишнего. Перечни по приказу №9 и есть формализация этого шага.
Статический анализ. Поиск в исходном коде опасных конструкций, скрытых веток, неиспользуемых интерфейсов, жёстко прописанных учётных данных. На верхних уровнях контроля анализ идёт глубже: до полноты покрытия кода тестами и соответствия исходников собранному бинарному файлу.
Контроль сборки. Проверка, что бинарный файл получен из представленных исходников и ничего не добавлено на этапе сборки. Хеши компонентов (методика требует их для компонентов из архивов исходников) служат именно этому.
Динамический анализ и тестирование. Проверка поведения программы на соответствие документации: недекларированная функция проявляет себя в сетевой активности, обращениях к файлам, реакции на нестандартные входные данные.
Проверка заимствованных компонентов. Открытый компонент проверяется на известные уязвимости по базам, включая БДУ ФСТЭК, и на соответствие заявленной версии. Здесь контроль НДВ смыкается с управлением уязвимостями: библиотека с известным дефектом в составе СЗИ может стать основанием для приостановления сертификата по пункту 83, если ФСТЭК установит факт несоответствия, и изготовителю выгоднее найти её раньше лаборатории.
Типичный случай: в составе продукта находится компонент версии, снятой с поддержки разработчиком компонента. Формально уязвимости в нём могут быть не описаны, но получить исправление уже негде. Такой компонент лаборатория, скорее всего, потребует обосновать или заменить: требования приказа №76 обязывают искать сведения о недостатках в заимствованных компонентах, и сделать это лучше до подачи заявки.
Что меняется в процессе разработки у изготовителя
Для изготовителя СЗИ приказ №9 и методика переводят состав продукта из справочной информации в контролируемый артефакт. Пять практических следствий.
Состав собирается в конвейере, а не руками. Перечень компонентов и образов, который лаборатория примет, генерируется на этапе сборки в CycloneDX с purl и, где требуется, хешами. Таблица, которую инженер заполняет перед подачей заявки, расходится с реальной сборкой после первого же обновления зависимости.
Реестр состава живёт между релизами. Пятидневный срок по пункту 73¹ считается от изменения перечня, а не от релиза. Обновили библиотеку с открытым кодом в ветке, которая войдёт в сертифицированную версию, значит, календарь уже пошёл. Момент «изменения перечня» приказ не определяет, практики пока нет; консервативная трактовка: любое расхождение с поданным перечнем считать изменением. Нужен процесс, который ловит такие изменения автоматически.
Один реестр, две выгрузки. Тот же реестр состава даёт перечень для ФСТЭК и SBOM для заказчиков, которые начали его запрашивать. Вести два разных документа об одном продукте дороже, чем один источник с двумя форматами выгрузки.
Решения по уязвимостям компонентов хранятся. Если известная уязвимость компонента в вашей сборке неэксплуатируема, обоснование записывается рядом с компонентом. Через два года при внесении изменений в сертифицированное средство лаборатория спросит именно об этом компоненте.
Техподдержка становится процессом с SLA. Устранение уязвимостей и НДВ, уведомление потребителей и доставка обновлений входят в обязанности заявителя по пункту 11 Положения, а прекращение поддержки даёт основание для приостановления сертификата. Заказчики после приказа №9 начнут вписывать сроки в договоры.
НДВ и уязвимости из БДУ: разные сущности, один реестр
В управлении безопасностью системы эти два потока сходятся в одной точке. Уязвимость известного компонента попадает в БДУ ФСТЭК с идентификатором, оценкой опасности и, как правило, ссылкой на CVE. Недекларированная возможность в базы не попадает до тех пор, пока её не найдут и не опишут как уязвимость. Но и то и другое требует от организации одного и того же: знать, какие продукты и каких версий установлены, из каких компонентов они состоят, и вести историю решений по каждой находке.
Практическое следствие для заказчика: реестр средств защиты с номерами сертификатов, версиями и датами обновлений должен быть связан с реестром уязвимостей. Тогда приостановление сертификата, новая запись в БДУ по компоненту продукта или уведомление поставщика об НДВ превращаются в задачу с ответственным и сроком, а не в письмо, которое прочитали и забыли. Как вести такой реестр, разобрано в статье «Реестр СЗИ в организации», ориентиры по срокам даёт методика ФСТЭК от 30.06.2025, а обязательные сроки для ГИС задаёт приказ №117 (п. 38: 24 часа и 7 дней).
🧾 Сертификаты, версии и уязвимости в одном контуре В КиберОснова реестр СЗИ с номером и сроком сертификата привязан к активам, на которых средство установлено, а модуль БДУ ФСТЭК сопоставляет установленные продукты с банком данных угроз и оценивает критичность с учётом окружения. Задачи на устранение получают срок по приказу №117 и ответственного.
Что делать заказчику: приёмка сертифицированного СЗИ после приказа №9
Восемь проверок при закупке или обновлении средства защиты. Они укладываются в один лист и закрывают большинство рисков, которые приказ №9 сделал видимыми.
- Сертификат действует. Номер и статус в реестре ФСТЭК, дата окончания, отсутствие приостановления. Проверять на дату поставки, а не на дату договора.
- Уровень доверия соответствует классу системы. ГИС 1 класса и ЗОКИИ 1 категории требуют 4 уровень или выше, 2 класса и 2 категории требуют 5, 3 класса и 3 категории 6.
- Уровень контроля НДВ известен. Он входит в уровень доверия (требования приказа №76: средство N уровня доверия проходит испытания по N уровню контроля), отдельного требования к нему в приказах №117, №239 и №21 сейчас нет. Запросить его у поставщика полезно для систем с актуальными угрозами 1-го и 2-го типов по ПП-1119.
- Перечень открытых компонентов передан. Для продуктов, сертифицированных или изменённых после 2 мая 2026 года, перечень существует по приказу №9, если в продукте есть открытые компоненты. Запрашивайте его в формате CycloneDX.
- Перечень образов контейнеров передан, если продукт поставляется в контейнерах.
- Дата последнего изменения перечня зафиксирована и совпадает с версией поставки. Расхождение означает, что вам передали состав другой версии.
- Условия технической поддержки. Сроки выпуска исправлений для уязвимостей и НДВ, порядок уведомления, канал доставки обновлений. Прекращение поддержки служит основанием для приостановления сертификата, и это должно быть в договоре.
- Известные уязвимости продукта проверены по БДУ ФСТЭК на момент приёмки, найденные заведены в реестр с решением.
📥 Чек-лист приёмки в Excel Восемь проверок с полями «что запросить», «где проверить», «результат», плюс лист «реестр СЗИ» для первых десяти продуктов. Скачать можно ниже. Проверить сертификат и уязвимости конкретного продукта — в реестре сертифицированных СЗИ.
Для изготовителя список короче и жёстче: перечни в заявке, CycloneDX из конвейера сборки, календарь на 5 дней для обновления перечня, процесс устранения уязвимостей и НДВ с уведомлением потребителей. Что стоит за словами «безопасная разработка» в ГОСТ Р 56939-2024, разобрано в статье «РБПО по ГОСТ Р 56939».
Коротко
Недекларированные возможности: функции ПО, не описанные в документации, через которые можно нарушить безопасность информации. Приказ ФСТЭК №9 от 20.01.2026 (действует с 02.05.2026) обязал изготовителей СЗИ прикладывать к заявке перечни открытых компонентов и образов контейнеров, обновлять перечень в 5 календарных дней и добавил непредставление таких сведений к основаниям приостановления сертификата на срок до 90 дней. Методика от 12.05.2026 заменила закрытую методику 2020 года, задала шесть уровней контроля и формат CycloneDX для описания состава. Заказчику важно: проверять сертификат и уровень доверия под класс системы, запрашивать перечни компонентов, держать реестр СЗИ связанным с реестром уязвимостей и прописывать техподдержку в договоре.
