Сертификация ФСТЭК для десктоп-приложения: что проверяют и как подготовиться

Сертификат ФСТЭК нужен не каждому продукту. Сначала выясните, нужен ли он вам. Если нужен, готовьтесь заранее: испытания — самая долгая часть сертификации, и к ним можно подготовиться до подачи заявки.

Про другие «сертификаты» и совместимость с ОС я писал раньше: три «сертификата» для российского ПО и Ready for Astra.

Нужна ли вам сертификация

Сертифицируют средства защиты информации. Приказ ФСТЭК № 55 относит к ним средства технической защиты информации, средства обеспечения безопасности информационных технологий и защищённые средства обработки информации.

Требование обычно приходит от заказчика. Чаще всего это государственная информационная система (ГИС), значимый объект КИИ, система обработки персональных данных или АСУ ТП.

Для ГИС с 1 марта 2026 года действует Приказ ФСТЭК № 117. Он заменил Приказ № 17 от 2013 года. Сертификат приказ требует для средств защиты информации (п. 71). Для прикладной программы без функций защиты я такого требования в нём не нашёл. Но заказчик может написать больше, чем в приказе: в ТЗ или в условиях закупки. Поэтому уточняйте у него.

Если в продукте есть встроенные средства защиты (аутентификация, шифрование, журналирование), спросите лабораторию или ФСТЭК, считается ли он средством защиты информации.

Что Приказ № 117 значит для разработчика

Приказ адресован оператору системы, не вам. Но то, что он требует от оператора, доходит до разработчика через ТЗ и договор. Вот что важно.

Уровень доверия задаёт класс системы. Оператор относит систему к классу защищённости К1, К2 или К3. Класс зависит от значимости информации и масштаба системы (федеральный, региональный, объектовый). От класса зависит, какие сертифицированные средства защиты подходят (п. 72):

Класс системы	Сертифицированные средства защиты: не ниже
К1	4 класса защиты и уровня доверия
К2	5 класса
К3	6 класса

Поэтому первый вопрос заказчику: какой класс у системы?

Безопасная разработка. Если оператор разрабатывает ПО сам, он применяет меры из разделов 4 и 5 ГОСТ Р 56939-2024. Если он заказывает ПО подрядчику, то может включить эти требования в ТЗ (п. 50). Будьте готовы объяснить, как у вас устроена безопасная разработка.

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

Уязвимости и обновления. Оператор устраняет критическую уязвимость или закрывает её компенсирующей мерой за 24 часа, высокую — за 7 календарных дней (п. 38). Обновления он проверяет на подлинность и целостность и тестирует до установки в рабочий контур. Бесконтрольная установка обновлений запрещена (п. 39). Средства защиты должны поддерживаться разработчиком на территории России, включая выпуск исправлений (п. 71).

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

Как проходит сертификация

В процессе участвуют четыре стороны: ФСТЭК, орган по сертификации, испытательная лаборатория и вы как заявитель. Лабораторию вы выбираете сами из реестра аккредитованных ФСТЭК. Орган по сертификации назначает ФСТЭК. Повлиять на этот выбор нельзя.

Девять этапов:

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

Самый объёмный этап — шестой. К нему и нужно готовиться.

Что проверяют на испытаниях

Требования к уровням доверия задаёт Приказ ФСТЭК № 76. Методы поиска уязвимостей и недекларированных возможностей (НДВ) описывает «Методика выявления уязвимостей и недекларированных возможностей». Доступ к ней ограничен. Чтобы получить её, отправьте во ФСТЭК официальное письмо.

Самые трудоёмкие проверки:

статический анализ кода;
динамический анализ;
фаззинг;
тестирование на проникновение;
проверка на НДВ;
анализ заимствованных компонентов (SCA).

По последним требованиям Методики лаборатория может принять результаты испытаний от самого разработчика. Если эти проверки уже работают у вас в CI/CD, вы экономите время и не собираете артефакты в последний момент.

Что подготовить заранее

Документы. Для подачи заявки нужны формуляр, технические условия или техническое задание, руководство пользователя и руководство администратора. Их оформляют по ЕСПД (ГОСТ 19).

Для испытаний по Приказу № 76 опишите:

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

Объём зависит от уровня доверия. При серийном производстве добавляется ГОСТ Р 56939-2024.

Процессы. Встройте проверки в CI/CD: статический анализ, сборку с санитайзерами, модульные тесты, фаззинг, учёт зависимостей. Тогда для сертифицируемой версии вы просто выгружаете артефакты из пайплайна.

Что исправить в коде

Дальше — мой опыт, а не требования ФСТЭК. Вот что я проверяю в C++/Qt-проектах в первую очередь.

Память. Ищите strcpy, sprintf, memcpy без проверки размера, выходы за границы массивов, use-after-free, переполнение целых при расчёте размера буфера. В старом коде на C и MFC всё это встречается часто.
Отладочные возможности. Скрытые ключи командной строки, тестовые меню, обход авторизации, мёртвый код в сборке. Для проверки на НДВ всё это выглядит как закладка.
Секреты. Пароли, токены и адреса тестовых серверов в коде и в истории репозитория.
Учётные записи по умолчанию. Оператор обязан отключить или переименовать встроенные привилегированные учётные записи и сменить их пароли (п. 48 Приказа № 117). Не закладывайте в продукт admin/admin, который нельзя убрать.
Журнал событий безопасности. Оператор собирает и анализирует такие события (п. 49). Дайте ему что анализировать: пишите входы, ошибки аутентификации, смену прав и настроек.
Зависимости. Составьте список библиотек с версиями (SBOM). Выясните, какая версия Qt попадает в поставку и какие уязвимости в ней известны.
Внешние процессы и модули. Запуск команд с данными от пользователя, загрузка библиотек по небезопасным путям, временные файлы в общих каталогах.
Сборка. Зафиксируйте версии компилятора и зависимостей, сделайте сборку воспроизводимой, включите защитные флаги.

После сертификата

Сертификат — не разовая отметка. Разработчик поддерживает продукт: устраняет уязвимости и НДВ, сообщает потребителям об обновлениях и об изменениях в документации. Проверки в CI помогают и здесь: при каждом новом выпуске вам снова нужно подтверждать соответствие.

В 2024 году ФСТЭК предложила упростить ресертификацию обновлений. Действующие правила уточняйте на момент подачи.

С чего начать

Узнайте у заказчика класс системы и то, нужен ли сертификат именно на ваш продукт.
Запросите Методику и запустите статический анализ. Так вы увидите масштаб работ.
Разберите результаты по категориям. Начните с памяти, секретов и НДВ.
Подключите проверки к CI и ведите список зависимостей.
Затем пишите документацию и выбирайте лабораторию.

Если у вас унаследованный MFC-проект и его нужно подготовить и перенести на Astra Linux, напишите мне. Я делаю аудит кода и портирование.

Источники

Приказ ФСТЭК России от 11.04.2025 № 117. Приказ изменялся в 2026 году, проверяйте актуальную редакцию.
Сертификация ФСТЭК: гайд, часть первая — подготовка (Хабр, eXpress)
Сертификация ФСТЭК: гайд, часть вторая — процесс сертификации (Хабр, eXpress)