Когда говорят о «сертификации ПО по линии ФСТЭК», важно сразу убрать распространённую путаницу. ФСТЭК России не занимается “одобрением любого программного продукта вообще”. Речь идёт о сертификации средств защиты информации и программных продуктов, в которых реализованы функции защиты информации, в системе сертификации ФСТЭК России. Базовая правовая рамка этой системы задаётся Положением о сертификации средств защиты информации, утверждённым постановлением Правительства РФ № 608, а организационный и процедурный порядок сегодня закреплён в приказе ФСТЭК России от 03.04.2018 № 55.
Для программных продуктов ключевой смысл сертификации такой: разработчик или изготовитель должен доказать, что его ПО или программное средство защиты соответствует установленным требованиям по безопасности информации, а само подтверждение соответствия выполняется в рамках системы, где участвуют ФСТЭК России, аккредитованные органы по сертификации и испытательные лаборатории. Испытательные лаборатории проводят сертификационные испытания и оформляют технические заключения и протоколы, а порядок сертификации включает подачу заявки, принятие решения, испытания, оформление экспертного заключения и выдачу либо отказ в выдаче сертификата.
Какие нормативные документы нужно знать
1. Постановление Правительства РФ от 26.06.1995 № 608.
Это базовый документ верхнего уровня, который устанавливает сам порядок сертификации средств защиты информации в Российской Федерации. Он задаёт правовую рамку всей системы.
2. Приказ ФСТЭК России от 03.04.2018 № 55.
Это главный рабочий документ по сертификации в системе ФСТЭК России. Он определяет состав участников системы, организацию и порядок сертификации продукции, формы заявок, процедуры испытаний, оформления экспертного заключения, выдачи сертификата, инспекционного контроля, внесения изменений в сертифицированное средство, продления, переоформления и прекращения действия сертификата.
3. Приказ ФСТЭК России от 02.06.2020 № 76.
Этот документ устанавливает 6 уровней доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий: от шестого, как самого низкого, до первого, как самого высокого. Для ПО это критично, потому что глубина требований к разработке, испытаниям и контролю зависит не только от типа продукта, но и от требуемого уровня доверия.
4. Профильные требования к конкретному типу продукта.
Сертификация идёт не “вообще по приказу № 55”, а по конкретным требованиям к нужному классу средства. Например, сегодня ФСТЭК публикует отдельные требования по безопасности информации к многофункциональным межсетевым экранам (приказ № 44), к системам управления базами данных (приказ № 64), к средствам виртуализации (приказ № 187), к средствам контейнеризации (приказ № 118), к средствам обнаружения и реагирования на уровне узла (приказ № 58). Это не исчерпывающий список, но он хорошо показывает принцип: сначала определяется тип продукта, затем — применимые к нему требования.
5. Приказ ФСТЭК России от 01.12.2023 № 240.
Это отдельный, уже самостоятельный контур: сертификация процессов безопасной разработки программного обеспечения средств защиты информации. Документ вступил в силу с 1 июня 2024 года и в 2025 году был обновлён. Он важен именно для тех разработчиков, которые хотят подтвердить не только свойства самого продукта, но и зрелость процессов безопасной разработки.
6. ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования».
Этот стандарт сейчас играет очень заметную роль в контуре безопасной разработки. ФСТЭК включает его в актуальные перечни документов, а в материалах по сертификации процессов безопасной разработки прямо увязывает с новым порядком сертификации.
7. Приказы ФСТЭК России № 147 и № 148 от 27.07.2023.
Первый регулирует порядок аттестации работников органов по сертификации и испытательных лабораторий, второй — правила выполнения отдельных работ по аккредитации таких органов и лабораторий. Это уже не про продукт напрямую, а про тех участников системы, которые имеют право проводить работы по подтверждению соответствия.
Как обычно проходит сертификация ПО
На практике сертификация ПО по линии ФСТЭК — это не “отдали программу в лабораторию и ждём бумагу”, а полноценный проект, где одновременно сходятся требования к продукту, к документации, к испытаниям и, всё чаще, к процессам разработки.
Шаг 1. Определить, что именно сертифицируется.
Первый вопрос — относится ли продукт вообще к средствам защиты информации или к программным продуктам, в которых такие средства реализованы. Второй — по какой схеме идёт работа: серийное производство или единичный образец/партия. В действующем регулировании этот выбор важен, потому что сертификация серийного производства и сертификация единичного экземпляра — это не одно и то же.
Шаг 2. Выбрать нормативную “цель” сертификации.
Нужно определить тип средства, применимые к нему требования по безопасности информации и требуемый уровень доверия. Ошибка именно на этом этапе потом обычно обходится дороже всего: если команда начала готовить документацию и архитектуру без правильной привязки к приказу по своему классу средства и к нужному уровню доверия, испытания почти гарантированно превратятся в цикл доработок.
Шаг 3. Подготовить продукт и доказательную базу.
До подачи заявки обычно нужно привести в порядок сам продукт, зафиксировать состав и версию, подготовить эксплуатационную и техническую документацию, описать функции безопасности, порядок настройки, ограничения применения, сценарии эксплуатации, а если продукт идёт через контур безопасной разработки — ещё и регламенты процессов разработки, сопровождения, обучения, обработки уязвимостей и выпуска обновлений. В общедоступных базовых актах нет одной “волшебной папки”, одинаковой для всех продуктов, но общий вектор именно такой: продукт должен быть воспроизводим, документирован и проверяем.
Шаг 4. Подача заявки и решение о проведении сертификации.
Приказ № 55 прямо относит к процедурам сертификации подачу заявки и принятие решения о проведении сертификации. Форма заявки предусмотрена приложением к Положению, и она адресуется ФСТЭК России. Для сертификации процессов безопасной разработки по приказу № 240 также предусмотрена отдельная форма заявки, которую подписывает руководитель изготовителя.
Шаг 5. Сертификационные испытания.
Испытания проводят аккредитованные испытательные лаборатории. По их итогам оформляются технические заключения и протоколы. Именно здесь выясняется, насколько продукт реально соответствует заявленным требованиям, а не только красиво описан на бумаге.
Шаг 6. Экспертиза результатов и решение по сертификату.
После испытаний оформляется экспертное заключение по результатам сертификации и проект сертификата соответствия, затем принимается решение о выдаче или отказе в выдаче сертификата. В действующем порядке это отдельные процедуры, а не “формальность после лаборатории”.
Шаг 7. Жизнь после получения сертификата.
На этом работа не заканчивается. Приказ № 55 отдельно регулирует маркирование, внесение изменений в сертифицированное средство, переоформление сертификата, продление срока действия, приостановление или прекращение его действия. Кроме того, заявитель обязан обеспечивать соответствие сертифицированного средства требованиям по безопасности информации. Проще говоря: сертификат — это не индульгенция на любые последующие изменения продукта.
Отдельно стоит помнить про контур безопасной разработки. По приказу № 240 сертификация процессов безопасной разработки осуществляется на основании договора с аккредитованным органом по сертификации. Для многих разработчиков ПО это уже не “дополнительная опция”, а способ заранее выстроить процессы так, чтобы сам продукт проходил сертификацию не через хаотичные авралы, а через управляемую систему.
Требования к сотрудникам по ролям
Здесь важно разделить две разные плоскости.
Первая — это обязательные требования к работникам органов по сертификации и испытательных лабораторий.
Вторая — это требования к команде самого разработчика, которая готовит продукт к сертификации.
1. Работники органа по сертификации и испытательной лаборатории
Для этих ролей требования жёстче и нормативно формализованы.
Орган по сертификации и испытательная лаборатория должны быть аккредитованы ФСТЭК России по соответствующей области. После изменений 2023 года в области аккредитации прямо выделена и сертификация процессов безопасной разработки программного обеспечения средств защиты информации.
Работники, выполняющие работы по оценке соответствия, проходят аттестацию. При тестировании оцениваются знания нормативных правовых актов, методических документов и национальных стандартов, которые устанавливают порядок сертификации, требования по безопасности информации и методики сертификационных испытаний. Кроме того, предусмотрено решение практических задач на материально-технической базе ФСТЭК России с использованием тестовых образцов средств защиты информации.
То есть по этим ролям можно говорить о реальном нормативном требовании: эксперт должен быть не просто “человеком с опытом”, а аттестованным специалистом, подтверждающим знания и практические навыки.
2. Команда разработчика, которая выводит ПО на сертификацию
Вот здесь важный нюанс: в общедоступных базовых документах нет универсальной нормы вида “нужно обязательно иметь 2 разработчиков, 1 тестировщика и 1 специалиста по ”. Для разработчика ФСТЭК и ГОСТ требуют не фиксированное штатное расписание, а наличие назначенных ролей, распределённых обязанностей, подтверждённой компетентности и выстроенных процессов. ГОСТ Р 56939-2024 прямо говорит, что регламенты процессов безопасной разработки должны содержать сведения об обязанностях сотрудников и их ролях, а обучение понимается как постоянное повышение квалификации, знаний и компетенций. Он также требует повышать осведомлённость сотрудников о типовых угрозах, ошибках и уязвимостях, а для службы технической поддержки — отдельно фиксировать роли, обязанности и обучение её сотрудников.
Поэтому для разработчика корректнее говорить не о “жёстком перечне должностей по приказу”, а о минимально разумной ролевой модели.
Руководитель проекта / владелец продукта.
Отвечает за запуск проекта сертификации, фиксирует состав и версию продукта, обеспечивает ресурсами, подписывает ключевые документы со стороны изготовителя. Это должна быть роль с реальными полномочиями, а не номинальный “координатор без права решения”.
ИБ-архитектор / регуляторный архитектор.
Это одна из самых критичных ролей. Такой специалист переводит требования приказов ФСТЭК и выбранного уровня доверия в архитектурные и функциональные требования к продукту. Именно здесь определяется, что надо реализовать в продукте, что описать в документации и что будет проверяться на испытаниях.
Ведущий разработчик / архитектор ПО.
Отвечает за техническую реализацию функций безопасности, корректность архитектуры, контроль изменений и воспроизводимость результата. Если архитектурное решение не совпадает с тем, что описано в документации и заявлено на испытаниях, проблемы начинаются почти сразу.
Тестировщик / специалист по сертификационным испытаниям / внутренний QA по безопасности.
Нужен не просто для “обычного функционального тестирования”, а для предварительной проверки продукта на соответствие ожидаемым требованиям, подготовки тестовых сценариев, воспроизведения замечаний и сопровождения взаимодействия с лабораторией.
DevSecOps / специалист по сборке и конфигурации.
Особенно важен, если продукт идёт с повышенными требованиями к уровню доверия или через контур безопасной разработки. Эта роль обычно отвечает за безопасность сборочной среды, управление артефактами сборки, контроль используемых секретов, воспроизводимость релизов и трассируемость изменений. Это уже не “удобство команды”, а часть доказательной базы зрелого процесса.
Технический писатель / специалист по нормативной документации.
Без этой роли сертификация почти всегда начинает буксовать. Сертифицируется не только код, но и описание того, как продукт устроен, как он настраивается, какие ограничения имеет, как обновляется, как сопровождается и как должна действовать эксплуатирующая сторона. Плохо оформленная документация может сорвать проект даже при технически хорошем продукте.
Специалист по сопровождению / менеджер по уязвимостям и обновлениям.
ГОСТ Р 56939-2024 уже не ограничивается этапом “разработали и забыли”. Требуются процессы технической поддержки, уведомления пользователей об обновлениях, информирования о выявленных уязвимостях и о временных компенсирующих мерах до выпуска исправления. Поэтому роль сопровождения и реакции на уязвимости становится нормативно значимой.
В маленькой компании часть этих ролей может совмещаться одним человеком. Но даже в этом случае важно, чтобы роли были формально назначены, обязанности были описаны, а обучение и компетенции были подтверждаемы документально. Именно это и ожидается при зрелом подходе к безопасной разработке.
Вместо вывода
Сертификация ПО по линии ФСТЭК — это не “бумага на программу” и не разовая проверка одного дистрибутива. Это проект на стыке регуляторики, архитектуры, разработки, испытаний, документации и сопровождения. Базовый нормативный каркас здесь дают постановление Правительства РФ № 608, приказ ФСТЭК № 55, приказ № 76 по уровням доверия, профильные требования к конкретному типу средства, а для зрелых разработчиков — ещё и контур безопасной разработки по приказу № 240 и ГОСТ Р 56939-2024.
Если смотреть на вопрос практично, то успешную сертификацию обычно проходят не те команды, у которых “есть хороший программист”, а те, у которых заранее выстроена связка: правильно выбранные требования, управляемая версия продукта, нормальная документация, внутренняя проверка до лаборатории и назначенные роли с понятной ответственностью. И именно в этом месте сертификация становится не только регуляторной задачей, но и маркером зрелости самого разработчика.
©Автор-эксперт: Владислав Халяпин