Как получить сертификат ФСТЭК на безопасную разработку: инструкция для CISO

ФСТЭК России — это федеральный орган исполнительной власти, который контролирует техническую защиту информации и безопасность информационных систем. Когда речь заходит о требованиях ФСТЭК, подразумевают сертификацию конкретной версии продукта или средства защиты информации — СЗИ.

Сертификат на процессы разработки безопасного ПО (РБПО) работает иначе. Регулятор проверяет выполнение процессов безопасной разработки на всех этапах жизненного цикла продукта: от проектирования архитектуры до сборки, тестирования, эксплуатации и сопровождения.

В таблице собрали основные особенности сертификации РБПО:

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

В процессе сертификации аудиторы интервьюируют команды, анализируют технологические артефакты — логи сборок, статический анализ исходного кода (Static Application Security Testing, SAST), анализ состава ПО (Software Composition Analysis, SCA), динамическое тестирование безопасности приложения (Dynamic Application Security Testing, DAST), трассировку изменений.

Существуют следующие требования к сертификации: нормативные, ресурсные и требования безопасности. 

Нормативная база

Процесс сертификации опирается на такие нормативы:

1. ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» — базовый стандарт, который определяет требования к 25 процессам разработки безопасного ПО. Обновленная редакция утверждена приказом Росстандарта № 1504-ст от 24 октября 2024 года и действует с 20 декабря 2024 года; пришла на смену версии 2016 года и адаптирована под методологии DevSecOps.

2. Федеральный закон № 152-ФЗ «О персональных данных» (ПДн) — устанавливает требования к защите ПДн.

3. Приказ ФСТЭК России от 01.12.2023 № 240 — устанавливает порядок сертификации процессов безопасной разработки СЗИ: как подается заявка, как выбирается орган по сертификации, как проводится оценка соответствия и на какой срок выдается сертификат (не более 5 лет). Действует с 1 июня 2024 года.

4. Информационное письмо ФСТЭК России от 25.09.2024 «О порядке испытаний и поддержки безопасности средств защиты информации» — обязывает разработчиков СЗИ предоставлять перечни заимствованных open-source компонентов (SBOM) и поддерживать их безопасность на всем сроке технической поддержки продукта.

5. Информационное письмо ФСТЭК России от 25.10.2024 № 240/24/5526 — ужесточает требования к стороннему системному ПО, на котором работают СЗИ (интерпретаторы, веб-серверы, серверы приложений): безопасная конфигурация, контроль целостности среды исполнения, песочницы/контейнеризация, оперативная замена компонентов при обнаружении в них уязвимостей.

6. ГОСТ Р 71206-2024 «Безопасный компилятор языков С/С++» — требования к инструментам разработки, предотвращающим уязвимости на этапе компиляции (защита от переполнения буфера, статический анализ при компиляции, Control Flow Integrity). Действует с 1 апреля 2024 года.

7. ГОСТ Р 71207-2024 «Статический анализ программного обеспечения. Общие требования» — определяет правила проведения SAST: классификацию ошибок (включая CWE), методы анализа потоков данных и управления, требования к минимизации ложных срабатываний. Действует с 1 февраля 2024 года и обязателен для разработчиков, претендующих на 4-й и выше уровень доверия ФСТЭК.

8. ГОСТ Р 59548-2022 «Защита информации. Регистрация событий безопасности» — устанавливает единые правила сбора и хранения логов: что регистрировать, как обеспечивать целостность записей, сколько их хранить. Действует с 1 марта 2022 года, обязателен при сертификации СЗИ по требованиям доверия.

9. ГОСТы серии 57580 — стандарты по безопасности банковских и финансовых операций. Они являются самостоятельным обязательным требованием для кредитно-финансовых организаций (со стороны ЦБ РФ) и не входят в перечень прямых требований сертификации РБПО по ГОСТ 56939-2024. Однако успешное прохождение сертификации по ГОСТ 56939 может служить весомым доказательством выполнения части требований ГОСТ 57580, но не заменяет ее полностью.

10. Приказ ФСТЭК России от 25 декабря 2017 г. № 239 — требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры (КИИ).

11. Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении (ФСТЭК России) — определяет порядок исследований при сертификационных испытаниях СЗИ по уровням доверия, включая статический и динамический анализ кода, фаззинг-тестирование и экспертизу кода. Разработчикам рекомендуется применять еt положения для организации внутренних процессов жизненного цикла ПО в соответствии с ГОСТ Р 56939-2024. 

ГОСТ не предписывает конкретную реализацию процессов — он определяет требования к результату. Например, обязательно сканировать код инструментами статического и композиционного анализа, но какой именно инструмент использовать, решает компания. Единственное условие — он должен быть на техподдержке вендора или представлять собой open source решение, поддерживаемое сообществом. 

Документы в перспективе

Нормативная база продолжает расширяться. Среди документов, которые сейчас находятся в разработке или недавно утверждены и в ближайшее время станут частью регуляторной практики:

• Методика анализа защищенности информационных систем (2025) — утверждена 25 ноября 2025 года, заменяет методику 2015 года и вводит обязательное использование результатов статического и динамического анализа, а также данных SBOM при анализе защищенности ГИС, ИСПДн и КИИ.

• Методика оценки уровня критичности уязвимостей (2025) — утверждена 30 июня 2025 года, вводит динамический пересчет критичности уязвимостей при появлении новых данных, например публичного эксплойта.

• Методика тестирования на проникновение (2025) — опубликована 8 сентября 2025 года, стандартизирует порядок проведения пентестов и закрепляет его как финальный этап проверки после функционального тестирования и анализа уязвимостей. Обязательна для ГИС и систем госорганов 1 и 2 классов защищенности, подключенных к интернету.

• ГОСТ «Композиционный анализ программного обеспечения» — на конец 2025 года находится в статусе проекта, прошедшего публичное обсуждение. Должен закрепить требования к SCA: идентификацию компонентов, формат SBOM (например, CycloneDX или SPDX), поиск CVE и анализ лицензионной чистоты.

• ГОСТ «Методика оценки уровня внедрения процессов РБПО» — проект, разрабатываемый Лабораторией Касперского в развитие ГОСТ Р 56939-2024. Должен ввести шкалу зрелости процессов (от начального до совершенствуемого уровня) и количественные метрики вместо качественных формулировок "что должно быть сделано".

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

Требования ФСТЭК к процессам безопасной разработки

Безопасный жизненный цикл разработки (Secure Software Development Lifecycle, SSDLC) включает практики безопасности на каждом этапе создания ПО.

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

• На этапе разработки необходим анализ исходного кода с помощью статических анализаторов (SAST), контроль зависимостей и компонентов с открытым кодом (SCA), код-ревью с фокусом на безопасность и применение безопасной разработки, следующей практикам безопасного программирования.

• На этапе тестирования нужно динамическое тестирование на уязвимости (DAST), фаззинг-тестирование (автоматизированная подача некорректных данных для выявления скрытых уязвимостей), а также проверка безопасности интеграций.

Необходимые ресурсы

Разберем, что нужно, чтобы получить сертификат ФСТЭК.

• Укомплектованная команда. В команду входят архитекторы продукта, закладывающие требования безопасности в архитектуру решения, архитекторы кибербезопасности, проектирующие защищенную архитектуру, разработчики, отвечающие за устранение найденных уязвимостей в коде, специалисты по безопасности приложений (Application Security, AppSec), DevSecOps-инженеры, встраивающие безопасность в процессы разработки, тестировщики, проверяющие безопасность на этапе тестирования, а также аналитик по управлению уязвимостями. Весь этот оркестр координирует CISO (Chief Information Security Officer — директор по информационной безопасности) или руководитель ИБ, который отвечает за стратегию безопасности в целом. 

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

• Набор инструментов. Инструменты подбираются так, чтобы закрывать безопасность на всех этапах разработки и эксплуатации. Для этого используют SAST-сканеры для анализа кода, SCA-инструменты для проверки зависимостей, DAST-системы для тестирования работающего приложения, платформы управления уязвимостями, а также системы контроля версий и CI/CD с встроенными проверками безопасности. Обычно компании начинают с готовых коммерческих решений, а по мере роста зрелости дополняют их собственными инструментами, при этом затраты на инструменты могут варьироваться от нескольких миллионов рублей (для средних компаний, использующих open-source с коммерческой поддержкой) до десятков миллионов рублей (для крупных предприятий с коробочными SAST/SCA/DAST-комплексами). 

Команда, инструменты и документация — это отправная точка, но получить сертификат недостаточно: документацию нужно поддерживать в актуальном состоянии все пять лет действия сертификата, пока процессы, команды и роли продолжают меняться. 25 процессов РБПО — это более двухсот связанных артефактов: руководство по безопасной разработке, регламенты на каждый процесс, приложения к ним. Если вести все это вручную в Word или на статичных страницах wiki, любое кадровое изменение или перестройка команды порождает лавину правок, и часть несоответствий неизбежно остается незамеченной до проверки аудиторов.

Cloud.ru, проходя сертификацию РБПО для платформы Cloud.ru Evolution Stack, решил эту проблему с помощью инструмента процессного моделирования.. С его помощью вместо набора разрозненных документов была построена единая цифровая модель, где организационная структура, роли, а также все 25 процессов и артефакты к ним явно связаны. Если один процесс передает артефакт другому процессу или роли, эта связь зафиксирована в модели — и при изменении, например, оргструктуры, система учитывает это при формировании обновленных отчетов в виде регламентов РБПО. 

Поверх модели была организована публикация документации: данные из системы моделирования бизнесс-процессов экспортируются в HTML, конвертируются в Markdown и автоматически синхронизируются с корпоративной wiki каждую ночь или по запросу. А для быстрого поиска по этому массиву документов развернута платформа с использованием RAG на собственных языковых моделях — она отвечает на вопросы сотрудников в естественной форме со ссылкой на нужный регламент, вместо того чтобы заставлять человека читать десятки страниц.

Такой подход применим не только облачным провайдерам: любая компания, которой предстоит сертификация РБПО или поддержание ее в дальнейшем, сталкивается с той же проблемой — растущим количеством связанных документов, которые быстро устаревают при изменениях в командах. 

Кто может получить сертификат

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

Для каких продуктов актуальна сертификация процессов РБПО

Важно различать два вида сертификации:

• Сертификат на продукт (средство защиты информации, СЗИ) подтверждает безопасность конкретной версии решения. 

• Сертификат на процессы РБПО — отдельный документ, который подтверждает, что компания выстроила безопасную разработку как таковую, и дополняет сертификацию СЗИ, а не заменяет ее.

Получение сертификата РБПО особенно актуально для компаний, которые разрабатывают продукты, подлежащие сертификации как СЗИ или используемые в значимых системах — например, антивирусы, фаерволы и системы обнаружения вторжений, платформы и ПО для КИИ, включая сервисы управления производством и системы диспетчерского управления и сбора данных (SCADA), облачные сервисы для хранения и обработки данных, корпоративные системы, работающие с персональными данными, банковские и финансовые системы, а также государственные информационные системы.

Если у такой компании уже есть сертификат на процессы РБПО, она может проводить часть испытаний при сертификации самого продукта (СЗИ) самостоятельно — это и сокращает сроки выпуска сертифицированных версий.

Пакет документов для получения сертификата ФСТЭК:

1. Руководство по безопасной разработке ПО — ключевой документ, описывающий все двадцать пять процессов РБПО, роли, инструменты и методы контроля.

2. Регламенты информационной безопасности: положение об управлении уязвимостями, процедуры моделирования угроз, правила работы с инцидентами безопасности и регламенты код-ревью и тестирования.

3. Описание архитектуры безопасности: схемы защищенной среды разработки, сегментация сетей и изолированные среды и контроль доступа к системам и данным.

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

5. Эксплуатационная документация инструментов: описание используемых SAST/SCA/DAST-систем, настройка CI/CD-конвейеров с проверками безопасности, процедуры работы с результатами сканирования.

6. Свидетельства о легальности ПО: договоры на коммерческие инструменты безопасности, лицензии на ПО и подтверждение права использования открытого ПО.

7. Подтверждение квалификации персонала: сертификаты специалистов по ИБ, свидетельства об обучении, матрица компетенций команды.

8. Артефакты, подтверждающие работу 25 процессов РБПО. 

Документы должны отражать рабочую практику. Аудиторы будут сверять регламенты с фактическим выполнением процессов.

Путь к сертификации можно разбить на семь последовательных шагов.

Шаг 1. Определение объекта сертификации

Первый шаг — четко определить, что именно будет сертифицироваться. Это могут быть процессы разработки конкретного продукта, линейки продуктов или всей разработки компании.

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

Чем шире область сертификации, тем сложнее процесс, но и преимущества больше — все продукты под единым зонтиком процессов.

Шаг 2. Подготовка процессов безопасной разработки

Это этап, который может занять несколько лет. Вот что входит в основные задачи:

• Аудит текущих процессов. Проведите независимую оценку зрелости процессов разработки с привлечением внешнего эксперта. Выявите зоны роста и составьте план работ.

• Внедрение DevSecOps-конвейеров (автоматизированные процессы разработки и доставки ПО со встроенной безопасностью). Встройте проверки безопасности в процесс разработки — от коммита (сохраненное изменение кода в системе контроля версий) до развертывания. Сделайте их обязательными для всех команд.

Для реализации DevSecOps-подхода и безопасной поставки приложений компании все чаще используют контейнерную инфраструктуру. Например, Evolution Managed Kubernetes позволяет развернуть управляемые Kubernetes-кластеры для разработки, тестирования и эксплуатации приложений, обеспечивая масштабирование ресурсов, централизованный мониторинг и гибкое управление сетевым взаимодействием. Такой подход упрощает внедрение CI/CD-процессов, контроль среды исполнения и выполнение требований к безопасной сборке и развертыванию ПО. 

• Развертывание инструментов безопасности. Внедрите SAST, SCA, DAST, системы управления уязвимостями. Настройте интеграцию с CI/CD.

• Создание защищенной среды разработки. Обеспечьте изолированные среды для разработки, тестирования и продакшена. Настройте контроль доступа и мониторинг.

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

• Усиление направления AppSec. Закрепите роль архитектора по кибербезопасности как ключевую. Это узкая специализация на стыке программирования, DevOps (подход к разработке и эксплуатации ПО, который объединяет разработчиков и специалистов по эксплуатации) и ИБ.

• Создание комитета по РБПО. Хотя это не прямое требование регулятора, внутренний коллегиальный орган помогает управлять процессами в компании. Комитет следит за актуальностью регламентов, выпускает приказы в области безопасной разработки и принимает заявки на совершенствование процессов.

Шаг 3. Разработка комплекта документов

На основе внедренных процессов разработайте руководство по безопасной разработке и сопутствующие регламенты.

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

Например, разработчик перед сдачей кода запускает SAST-анализ в CI/CD, стандарт требует отсутствия критических уязвимостей, проверка считается выполненной при чистом отчете сканера, за внедрение и настройку CI отвечает DevOps-инженер, за устранение уязвимостей — разработчик, а успешность процесса измеряется долей релизов без критических замечаний и временем устранения найденных уязвимостей.

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

Шаг 4. Выбор органа по сертификации, аккредитованного ФСТЭК

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

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

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

Шаг 5. Подача заявки на сертификацию процессов безопасной разработки программного обеспечения

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

После одобрения заявки назначается орган по сертификации, который проводит проверку.

Как проходят проверки:

1. Проверка регламентов и артефактов. Первым делом аудиторы проверяют наличие и наполнение всех 25 регламентов и артефактов к ним. Руководство по РБПО, поданное во ФСТЭК вместе с заявкой на сертификацию, проверяется совместно специалистами ФСТЭК и органа по сертификации. 

2. Очные встречи. Аудиторы изучают реализацию всех 25 процессов РБПО в формате очных встреч.

3. Разбор кейсов. Могут попросить показать, как была обнаружена конкретная уязвимость, как проведен ее триаж, как исправлена и соблюдены ли сроки устранения (SLA).

4. Проверка артефактов. Изучают логи сборок, отчеты сканеров, трассировку изменений, документацию по инцидентам.

5. Проверка легальности ПО. Запрашивают договоры закупок, чтобы убедиться, что все коммерческие инструменты лицензированы.

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

Шаг 6. Устранение замечаний

После проверок аудиторы предоставляют список замечаний — критических и рекомендательных.

• Критические замечания блокируют выдачу сертификата. При выдаче органом по сертификации замечания, препятствующего проведению сертификации, все проверки останавливаются, и заявителю дается месяц на устранение с предоставлением доказательств исправления. 

• Рекомендательные замечания не влияют на получение сертификата, но указывают на зоны улучшения процессов.

Устраняйте замечания. Регулятор проверяет не только исправление конкретной проблемы, но и внедрение мер, предотвращающих ее повторение.

Шаг 7. Получение сертификата ФСТЭК

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

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

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

Подготовка процессов: 2-3 года

Это самый длительный этап сертификации ФСТЭК России. Сроки зависят от стартового уровня зрелости:

• Если DevSecOps-практики уже внедрены (есть SAST/SCA/DAST, CI/CD с проверками), на доработку и документирование требуется 6-12 месяцев.

• Если процессы безопасной разработки создаются с нуля (нет ничего или только базовые регламенты), полное внедрение занимает от двух до трех лет.

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

Разработка документации: 4-6 месяцев 

Подготовка руководства по безопасной разработке и сопутствующих регламентов занимает два-четыре месяца при наличии выделенной команды.

Подача заявки и согласование: 1-2 месяца

После подачи заявки во ФСТЭК требуется время на рассмотрение и назначение органа по сертификации.

Сертификационные проверки: 3-6 месяцев

Непосредственно процесс сертификации после подачи заявки занимает до полугода работы с органом по сертификации. Сроки зависят от:

• сложности архитектуры продуктов;

• количества процессов и команд;

• наличия замечаний по ходу проверки;

• загруженности органа по сертификации.

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

Стоимость сертификации РБПО фиксированная и регулируется государством. При этом стоимость может меняться. Дополнительно к этому общие затраты на внедрение (покупка/разработка SAST/SCA/DAST, адаптация CI/CD, обучение, доработка инфраструктуры) для средней или крупной компании могут составлять десятки миллионов рублей в год и не входят в цену самой сертификации. 

Окупаемость инвестиций:

• экономия на повторных сертификациях продуктов;

• снижение стоимости устранения уязвимостей за счет раннего обнаружения;

• ускорение выпуска обновлений;

• конкурентные преимущества при работе с заказчиками из госсектора;

• повышение доверия клиентов и партнеров.

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

• В первую очередь необходимо изучить ГОСТ Р 56939-2024 — все шаги, описанные ниже, должны соответствовать его требованиям. 

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

• Также должен быть внедрен процесс безопасной разработки. Это означает, что DevSecOps-конвейеры работают для всех команд, обязательные проверки безопасности встроены в CI/CD, процессы моделирования угроз и анализа рисков документированы, код-ревью включает проверку безопасности, а управление уязвимостями ведется с соблюдением регламентных сроков.

• Надо развернуть инструменты. Речь идет о SAST-сканерах для статического анализа, SCA-системах для контроля зависимостей, DAST-инструментах для динамического анализа, платформе управления уязвимостями, а также системах мониторинга и логирования.

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

• Отдельно проверяется готовность документации. Руководство по безопасной разработке должно соответствовать ГОСТ, регламенты информационной безопасности — описывать все процессы, матрица ролей должна быть заполнена, эксплуатационная документация инструментов — подготовлена, а легальность используемого ПО — подтверждена.

• Не менее важна и команда: назначены Security Champions в командах разработки, сотрудники прошли обучение практикам безопасной разработки, понимают свои роли в процессах РБПО, а достаточность ресурсов подтверждена расчетами.

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

Завершающим этапом становится внутренний аудит безопасности: проводится независимая оценка зрелости процессов, выявляются и устраняются критические пробелы, проверяется работа 25 процессов РБПО и подготавливаются артефакты для демонстрации аудиторам. Если все пункты выполнены, компания готова подавать заявку на сертификацию.

Сертификация процессов безопасной разработки ПО по ГОСТ Р 56939-2024 — это подтверждение зрелости процессов разработки, от проектирования до эксплуатации.

Преимущества сертификата:

1. Релизный цикл. Наличие сертификата РБПО дает компании возможность проводить испытания самостоятельно, это сокращает время выпуска изменений к сертификату продукта. Если сертификация проводится с изменением функций безопасности, нужно привлекать лабораторию.

2. Экономия на устранении уязвимостей. Вместо проверки безопасности перед релизом, искать и исправлять проблемы можно на этапе написания кода. Чем раньше обнаружен дефект, тем дешевле обойдется его исправить.

3. Повышение качества кода. Внедрение практик secure by design улучшает общую инженерную культуру. Невозможно использовать предсобранные внешние компоненты без проверки — все зависимости сканируются на наличие уязвимостей.

4. Конкурентные преимущества. Сертификат ФСТЭК — сильный сигнал для заказчиков, особенно из госсектора и компаний с высокими требованиями безопасности. Но важно понимать, что сертификация добровольная, и ФСТЭК на данный момент не настаивает на включении этого требования в условия госзакупок. Однако ситуация может измениться — а пока в стране выдано только восемь таких сертификатов, ранний выход на сертификацию дает компании заметное преимущество. 

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

Стоимость сертификации складывается из двух частей: оплата работы органа по сертификации (сумма обсуждается индивидуально) и стоимость внедрения инструментов и содержания специалистов — это уже многие миллионы рублей сверху. 

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