От добровольной практики – к требованию закона
Еще несколько лет назад безопасная разработка программного обеспечения (РБПО) воспринималась как меры рекомендательного характера для отдельных компаний. Ежегодно число выявленных уязвимостей в ПО только возрастало, а сложные атаки с использованием дефектов исходного кода всё чаще и чаще приводили к инцидентам с разной степенью ущерба. Вместе с этим разработчики прекрасно понимали, что успех их продуктов напрямую завязан на качество и безопасность. Однако нормативные требования и регулирование безопасной разработки вовсе отсутствовали.
Первым отечественным стандартом в этой области стал ГОСТ Р 56939-2016, и его со временем сильно переработали. В расширенном и обновленном виде он перерос в ГОСТ Р 56939-2024. В нём сделан акцент на проактивное устранение уязвимостей, а основная часть содержит описание конкретных шагов, которые нужны, чтобы выстроить 25 процессов РБПО с указанием целей, требований к реализации этих процессов и подтверждающих артефактов.
Что изменилось?
Параллельно с выходом стандартов всё в более явном виде предъявляются требования к ПО, предназначенного для информационных систем разного класса защищённости. Так, например, в приказе ФСТЭК России №239 есть пункт 29.3, и он обязывает задействовать в контуре ЗО КИИ софт только тех вендоров, кто имеет руководство по безопасной разработке, использует инструменты для анализа кода и на регулярной основе занимается выявлением и устранением уязвимостей.
А новый приказ регулятора №117 в пункте 50 рассматривает две ситуации:

ИТ-продукты для государственных инфосистем создаёт сам оператор.
Их пишет подрядчик.

В обоих случаях должны быть реализованы меры, предусмотренные разделами 4 и 5 ГОСТа Р 56939-2024. Если оператор привлекает организацию-подрядчика, к ней могут быть предъявлены те же самые требования. Подтвердить, что процессы реализованы по этому ГОСТу, можно с помощью их сертификации в соответствии с приказом ФСТЭК России №240.
Дальнейшие тенденции
Получается, что наличие реализованных процессов РБПО не просто добавляет конкурентных преимуществ вашему продукту, но и напрямую влияет на право его дальнейшего существования. «Группа Астра» одной из первых прошла путь сертификации собственных процессов РБПО, благодаря чему в компании сформировался подход, который распространяется на все её команды разработки.
Концептуально мы разделили его на 4 основных этапа.
Этап 1
В начале любого проекта необходимо провести аудит. Собираем и анализируем информацию: как сейчас у разработчиков устроена инфраструктура, какие они используют СЗИ и инструментальные средств анализа кода, смотрим, как налажены процессы в соседних командах. Затем ИБ-эксперты моделируют угрозы, описывают поверхность атаки для разрабатываемого софта, анализируют риски и готовят технический проект, по которому выстраивается защищённая платформа РБПО.
Разумеется, каждый этап и сформированный процесс сопровождаются артефактами. В данном случае это отчёт о результатах исследования, где указано, какие из предусмотренных ГОСТом Р 56939-2024 процессы РБПО уже реализованы, а какие ещё нет. Составляются дорожная карта построения недостающих процессов и план конкретных мероприятий, которые нужны, чтобы обеспечить соответствие стандарту.
Этап 2
Дальше приступаем к внедрению защищённой платформы РБПО. В соответствии с техническим проектом интегрируем и настраиваем инфраструктурные решения и СЗИ, подбираем средства инструментального анализа кода в зависимости от тех технологий и языков программирования, что используют команды. Всю платформу приводим к усиленным настройкам безопасности, оцениваем, насколько принятые меры эффективны и отвечают конкретным требованиям регуляторов.
В итоге получаем сформированную и настроенную платформу РБПО в защищённом виде и подтверждение, что она готова к эксплуатации, включая аттестацию по требованиям приказа ФСТЭК России №77.
Этап 3
Когда платформа развёрнута, мы подходим к выстраиванию процессов безопасной разработки в командах с самого начала жизненного цикла ПО. В первую очередь формируются и поддерживаются правила кодирования, экспертизы исходного кода, его статического и динамического анализа, использования инструментов композиционного анализа, а также функционального и нефункционального тестирования.
Естественно, каждый из этих процессов следует регламентировать и описать в документации. Данный этап один из самых трудоёмких и продолжительных. Он также требует выделения дополнительной роли — Security Champion — того, кто максимально погружен во внутренние процессы команды и нацелен на их оптимизацию и регламентацию в соответствии с ГОСТом Р 56939-2024.
Этап 4
И в завершение, когда работа ИБ-команды налажена и тесно переплетена с действиями разработчиков, необходимо оформить процессы передачи продукта в эксплуатацию, его дальнейшего технического сопровождения и поддержки безопасности. Создаём руководства по использованию средств мониторинга, регламенты техподдержки и реагирования на ИБ-инциденты. Выстраиваем процессы проактивного поиска и устранения уязвимостей, в том числе с помощью внешнего анализа ПО и тестирования на проникновение.
Основной фокус
При формировании нашего подхода мы фокусировались на трёх основных вещах:
1. Люди – профильные специалисты, вовлечённые в процесс разработки.
2. Технологии и инструменты, что используются при создании ПО.
3. Процессы, которые связывают всё в единый чётко работающий организм.
В центре внимания у нас всегда собственные сотрудники: их надо обучать не только на всех этапах построения процессов безопасной разработки, но и дальше. Нужно составить для каждого из них план развития и ежегодно его корректировать, дополнять и обновлять.
Выводы
Наша методика построения процессов РБПО обеспечивает комплексный подход к ИБ. Если заблаговременно находить и исправлять ошибки кода, в частности, задействовать Shift Left вместе с механизмами разработки безопасного софта, то можно повысить его стабильность, надёжность и при этом снизить свои затраты.
Соответствие нормативным требованиям, использование современных инструментов анализа кода и следование лучшим практикам Security by Design помогают не просто получить разрешение применять то или иное решение в инфосистемах, на которые распространяются требования регуляторов, а делать продукты действительно надёжными и устойчивыми к кибератакам.
Внедрение РБПО — это инвестиция в долгосрочную безопасность и доверие пользователей, что в итоге определяет успех любого ИТ-проекта.

Автор: Никита Подотыкин, эксперт по информационной безопасности компании Астра Консалтинг.