«Мы стали гораздо строже к себе»: CISO Cloud.ru Сергей Волков — об опыте сертификации процессов безопасной разработки ПО

Что за сертификат РБПО?

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

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

Сертификация подтверждает фактическое выполнение 25 процессов РБПО: анализ исходного кода, использование безопасной системы сборки, безопасная поставка ПО, поиск уязвимостей при эксплуатации и другие. В ходе проверки аудиторы проводят интервью с командами, анализируют технологические артефакты (логи сборок, отчеты инструментов сканирования SAST/SCA/DAST, трассировку изменений) и оценивают реальный уровень внедрения практик — сам факт наличия внутренних регламентов не является подтверждением соответствия ГОСТу.

Как подготовиться к получению сертификата?

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

Cloud.ru начал этот путь в 2021 году, когда стали появляться первые инструментальные средства безопасности: сканеры защищенности, платформы управления уязвимостями. В 2024 году компания провела независимый аудит зрелости процессов разработки с привлечением внешнего эксперта, выявила зоны роста и составила план работ — какие практики нуждаются в пересмотре, каких инструментов не хватает. Целью было получить сертификат к концу 2025 года, поскольку на осень была намечена первая сертификация СЗИ модульной платформы Evolution Stack для создания частных и гибридных облаков, и компании было важно двигаться в соответствии с релизным циклом.

Первое требование ФСТЭК — руководство по безопасной разработке, соответствующее требованиям ГОСТ. Без него регулятор не примет заявку на сертификацию. Cloud.ru построил DevSecOps-конвейеры, сделал их обязательными для всех команд разработки, а затем разработал регламенты, учитывающие и формальные требования стандарта, и реальные инженерные практики и инструменты компании.

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

Помимо классических практик — моделирования угроз, определения поверхности атаки, Cloud.ru внедрил ранее не использовавшиеся методы, в частности, фаззинг-тестирование. Суть метода — в автоматизированной подаче на вход функции большого объема некорректных, случайных или специально искаженных данных. Цель — спровоцировать и отследить аномальное поведение (падения, утечки памяти или зависания), которое указывает на скрытые уязвимости и недостатки. В отличие от традиционных тестов, фаззинг выявляет непредсказуемые пограничные случаи. Это ресурсоемкая методика, требующая значительных мощностей и экспертизы, поэтому полноценные фаззинг-стенды чаще встречаются в крупных технологических компаниях, а не как массовая практика.

После инвентаризации процессов, Cloud.ru обучил инициативную группу сотрудников, ставших ответственными за внедрение практик (Security Champions) в своих командах. На основе этих материалов готовятся внутренние курсы для всех разработчиков – более 700 человек. Мы также существенно усилили направление AppSec в собственном Центре киберзащиты, закрепив роль архитектора по кибербезопасности как ключевую. Это узкая специализация на стыке программирования, DevOps и ИБ, требующая серьезной подготовки, таких специалистов на рынке крайне мало.

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

Как устроен процесс проверки?

Завершив подготовку, компания подает заявку во ФСТЭК с приложенным руководством по безопасной разработке. Количество попыток не ограничено: можно получить отказ, исправить замечания и подать снова. После одобрения заявки назначается орган по сертификации. В случае Cloud.ru проверку проводил ИСП РАН.

Проверки проходят в формате очных встреч. Аудиторы детально изучают реализацию всех 25 процессов РБПО. Например, могут попросить показать, как была обнаружена конкретная уязвимость, как проведен ее триаж, как исправлена и соблюдены ли сроки устранения (SLA). Также проверяется легальность используемого ПО, проверяющие могут запросить договоры закупок, чтобы убедиться, что все коммерческие инструменты лицензированы.

Для облачных провайдеров оценка имеет свою специфику. Облачная платформа — это сотни взаимосвязанных микросервисов с различным технологическим стеком. Cloud.ru Evolution Stack включает множество компонентов, поддержку которых обеспечивают десятки команд разработки. Такая архитектура требует сложной координации процессов безопасности на каждом этапе жизненного цикла.

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

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

Какие преимущества дает сертификат?

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

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

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

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

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

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