Secure SDLC: безопасная разработка ПО для КИИ — практический подход

Secure SDLC — это не «дополнительные галочки в проекте». Это полная перестройка процесса разработки ПО, в котором безопасность встроена в каждый этап от анализа требований до эксплуатации. Для ПО, предназначенного для КИИ или государственных систем, это уже не вопрос «нужно ли», а вопрос «как внедрить». В обновлённой редакции приказа ФСТЭК № 239 (2022 год) требования к процессу разработки стали частью обязательных мер защиты значимых объектов.

Эта статья — для CTO, руководителя разработки или CISO, который выстраивает или модернизирует процесс безопасной разработки в команде. К концу гайда у вас будет ясная картина: что такое Secure SDLC, какие инструменты использовать, как организовать pipeline, как моделировать угрозы и сколько стоит внедрение.

Что такое Secure SDLC

Обычный SDLC — последовательность этапов разработки: анализ требований, проектирование, разработка, тестирование, развёртывание, эксплуатация. Secure SDLC — тот же процесс, но с встроенными в каждый этап практиками безопасности.

Анализ требований:

• Сбор требований безопасности от заказчика и регулятора (для КИИ — приказы ФСТЭК)
• Классификация обрабатываемой информации
• Определение применимых регуляторных рамок (№ 239, № 21, № 17)

Проектирование:

• Моделирование угроз (по методике ФСТЭК для КИИ, STRIDE для коммерческого ПО)
• Безопасная архитектура (изоляция, разграничение, минимизация поверхности атаки)
• Выбор сертифицированных компонентов (СКЗИ, СЗИ от НСД, СОВ)
• Проектирование подсистемы аудита

Разработка:

• Стандарты безопасного кодирования (OWASP Secure Coding Practices)
• Pre-commit hooks для базовой проверки
• SAST на каждый коммит и pull request
• SCA для новых зависимостей
• Управление секретами (никаких credentials в коде)
• Peer review с фокусом на безопасность

Тестирование:

• Unit-тесты с учётом security сценариев
• Интеграционные тесты безопасности
• DAST на тестовом стенде
• Тесты на проникновение перед мажорными релизами
• Регрессионные сценарии безопасности

Развёртывание:

• Контейнерное сканирование на уязвимости
• Проверка конфигураций инфраструктуры
• Защищённые каналы доставки
• Подпись релизов и контроль целостности

Эксплуатация:

• Мониторинг безопасности (SIEM)
• Реагирование на инциденты
• Регулярное обновление зависимостей
• Постпродажный надзор (для медизделий, КИИ-продуктов)
• Управление жизненным циклом уязвимостей

Это не «добавить SAST в pipeline» — это полный пересмотр процессов разработки. Для команды 10-20 разработчиков переход на Secure SDLC занимает 6-12 месяцев.

Моделирование угроз

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

Методики моделирования

STRIDE (Microsoft). Шесть категорий угроз:

• Spoofing — выдача себя за другого
• Tampering — подделка данных
• Repudiation — отказ от авторства действия
• Information disclosure — утечка информации
• Denial of Service — отказ в обслуживании
• Elevation of Privilege — повышение привилегий

Применяется к каждому компоненту системы. Универсальная методика для коммерческого ПО.

PASTA (Process for Attack Simulation and Threat Analysis). Семь этапов:

1. Определение бизнес-целей
2. Описание технического объёма работ
3. Декомпозиция приложения
4. Анализ угроз
5. Идентификация уязвимостей
6. Анализ атак
7. Анализ риска

Применяется для крупных проектов с серьёзными требованиями к ИБ.

Методика ФСТЭК (2021). Для российских КИИ-проектов — обязательная. «Методический документ по моделированию угроз безопасности информации» с поправками 2023 года. Структура:

• Описание объекта
• Идентификация активов
• Анализ возможностей нарушителей
• Идентификация актуальных угроз
• Определение уровня опасности угроз
• Рекомендации по нейтрализации

Документ — 50-150 страниц на типовой объект КИИ.

Когда проводить

Моделирование угроз должно быть в начале проекта, на этапе проектирования архитектуры. Пытаться сделать threat modeling в конце разработки — это исправление архитектурных ошибок постфактум, что обычно стоит в 5-10 раз дороже.

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

Кто проводит

• CISO или архитектор ИБ — основная роль
• Архитектор системы — обеспечивает понимание архитектуры
• Лид-разработчик — даёт реалистичное понимание кода
• Внешний консультант — для первого опыта или сложных проектов

Время на моделирование — 2-4 недели на типовой проект, 4-8 недель на крупный.

SAST: статический анализ кода

SAST анализирует исходный код без его выполнения. Выявляет:

• SQL-инъекции
• XSS-уязвимости
• Hard-coded credentials
• Использование небезопасных функций
• Неправильную работу с криптографией
• Проблемы управления памятью

Популярные инструменты

Зарубежные (для коммерческого ПО без КИИ):

• SonarQube — open-source, есть платная версия. Стандарт де-факто для большинства команд.
• Checkmarx — enterprise-уровень, дорогой, мощные правила.
• Veracode — облачный сервис.
• Fortify — старый и стабильный.

Отечественные (для КИИ и сертифицируемого ПО):

• Solar appScreener (Ростелеком-Солар) — самый распространённый в РФ, поддерживает 30+ языков.
• PT Application Inspector (Positive Technologies) — глубокий анализ, хорошие правила для веб-приложений.
• InfoWatch Code Inspector — модуль крупного DLP-стека.

Для сертифицируемого во ФСТЭК ПО используются отечественные инструменты.

Интеграция в pipeline

Стандартная схема:

• На каждый коммит — быстрый SAST на изменённых файлах (1-3 минуты в pre-commit hook или CI)
• На pull request — полный SAST на всём проекте (5-15 минут) с блокировкой merge при critical/high
• Раз в неделю — глубокий SAST с расширенным набором правил
• Раз в квартал — анализ false positives, тюнинг правил

Настройка — 1-2 недели для типового проекта.

DAST: динамический анализ

DAST тестирует работающее приложение, имитируя действия атакующего. Выявляет:

• Уязвимости аутентификации и сессий
• Проблемы безопасности конфигурации
• Уязвимости бизнес-логики
• Проблемы с API
• Misconfigurations серверов

Популярные инструменты

Open-source:

• OWASP ZAP — бесплатный, активное сообщество.
• Nikto — простой сканер для веб-серверов.

Коммерческие:

• Burp Suite Professional — стандарт для пентестеров.
• Acunetix — автоматический сканер уязвимостей.
• Netsparker — облачный или on-premise.

Отечественные:

• PT BlackBox (Positive Technologies)
• MaxPatrol — комплекс с DAST-функционалом

Интеграция в pipeline

• На тестовом стенде после деплоя — автоматический DAST (15-60 минут) перед промоушеном на стейдж
• Раз в неделю — полный регрессионный DAST на стейдже
• Перед мажорным релизом — ручной пентест экспертами

SCA: контроль зависимостей

SCA анализирует open-source компоненты в проекте.

Что проверяется

• Известные уязвимости (CVE). База NIST NVD, GitHub Security Advisories, отечественный БДУ ФСТЭК.
• Лицензии. Совместимость с коммерческим использованием. GPL и AGPL — ограничения, MIT и Apache 2.0 — гибкость.
• Версии. Устаревшие, недокументированные.
• Транзитивные зависимости. Реальный «дерево» может содержать 1000+ компонентов из 100 прямых зависимостей.

Инструменты

Зарубежные:

• Snyk — лидер рынка, отличная база уязвимостей.
• Sonatype Nexus — корпоративный стандарт.
• WhiteSource / Mend — глубокий анализ.
• GitHub Dependabot — встроен в GitHub, бесплатен для open-source.

Отечественные:

• Solar appScreener (модуль SCA)
• CodeScoring — российская разработка

Процесс

1. Полная инвентаризация компонентов
2. Базовая проверка известных CVE
3. План закрытия критических — обновление, замена, форк с патчем
4. Регулярный мониторинг (ежедневное обновление баз)
5. Политика добавления новых зависимостей — review CISO/security-чемпиона

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

Безопасная архитектура

Принципы, которые должны быть заложены на этапе проектирования.

Принцип минимальных привилегий. Каждый компонент имеет только необходимые права. База данных не имеет доступа в интернет. Веб-сервер не может писать в системные директории. Микросервисы изолированы между собой.

Defense in Depth (эшелонированная защита). Несколько уровней защиты: периметр (МЭ), сегментация (внутренние МЭ), хост-уровень (СЗИ от НСД, антивирус), приложение (валидация, аутентификация), данные (шифрование).

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

Полная медиация. Каждый запрос проходит через проверку прав. Никаких «доверенных зон» без аутентификации.

Открытый дизайн. Безопасность не должна зависеть от секретности дизайна — только от секретности ключей.

Минимизация поверхности атаки. Удаление неиспользуемых функций, портов, компонентов. Чем меньше кода — тем меньше уязвимостей.

Разделение обязанностей. Разработчик не имеет доступа к production. Администратор не пишет код. Аудитор не вмешивается в эксплуатацию.

Управление инцидентами в эксплуатации

Secure SDLC не заканчивается релизом. В эксплуатации обязательны процессы реагирования на новые угрозы и уязвимости.

Мониторинг

• SIEM — централизованный сбор событий безопасности (MaxPatrol SIEM, RuSIEM, Solar)
• Application monitoring — мониторинг приложения (Prometheus, Grafana)
• WAF (Web Application Firewall) — защита от типовых атак на веб-приложения
• RASP (Runtime Application Self-Protection) — защита приложения в runtime

Реагирование

• Regулярные обновления зависимостей. Каждый день — проверка новых CVE, при критических — экстренное обновление.
• Hot patches. Возможность развернуть исправление за 1-4 часа при критической уязвимости.
• Incident response team. Команда, которая реагирует на инциденты в режиме on-call.

Постпродажный надзор

Особенно важно для ПО, сертифицированного во ФСТЭК или работающего в КИИ:

• Регулярные отчёты регулятору о выявленных уязвимостях
• Уведомление пользователей о критических обновлениях
• Документирование инцидентов

Сроки и бюджет внедрения

Этап	Срок	Бюджет
Аудит текущего процесса	1 месяц	0,3-0,5 млн ₽
Моделирование угроз для существующих продуктов	1-2 месяца	0,4-1 млн ₽
Внедрение SAST в pipeline	2-3 месяца	0,5-1,5 млн ₽ (лицензии) + 0,2-0,4 млн ₽ (внедрение)
Внедрение SCA в pipeline	1-2 месяца	0,3-0,8 млн ₽ (лицензии) + 0,1-0,3 млн ₽ (внедрение)
Внедрение DAST	2-3 месяца	0,3-0,8 млн ₽ (лицензии) + 0,2-0,4 млн ₽ (внедрение)
Обучение команды	1-2 месяца	0,3-0,6 млн ₽
Регламенты и документация	1-2 месяца	0,3-0,5 млн ₽
Итого первичное внедрение	6-12 месяцев	2-6 млн ₽
Регулярная поддержка (год)	—	1-2 млн ₽

Для крупных команд 50+ разработчиков — 4-6 млн ₽ за 8-14 месяцев. Окупаемость — через избежание серьёзных инцидентов, готовность к сертификации, скорость release-цикла.

Типичные ошибки внедрения

Внедрение «сверху вниз» без вовлечения разработчиков. Решение CISO купить инструмент и заставить разработчиков использовать. В результате — массовое игнорирование, формальный pipeline без эффекта.

Слишком много false positives. Без тюнинга правил SAST даёт 70-90% ложных срабатываний. Команда быстро перестаёт обращать внимание. Решение — тщательная настройка под технологический стек проекта.

Игнорирование SCA. Команда фокусируется на собственном коде, забывая про 60-80% кода в open-source. На испытаниях во ФСТЭК выясняется, что в зависимостях 30+ критических CVE.

Отсутствие моделирования угроз. SAST/DAST/SCA развёрнуты, но без модели угроз неясно, что именно защищать. Получается «защита всего одинаково», что неэффективно.

Отсутствие отечественных инструментов. Команда использует SonarQube + Snyk, что не подходит для КИИ-проектов. При попытке сертификации — переход на Solar appScreener или PT Application Inspector с потерей 2-4 месяцев на настройку.

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

С чего начать внедрение

Реалистичный план для команды разработки.

1. Аудит процесса. Где сейчас находитесь, что есть, что нужно. 2-4 недели, 200-500 тыс ₽.
2. Моделирование угроз для одного продукта. Пилотный проект — выбрать самый критичный продукт и провести threat modeling. 3-4 недели.
3. Внедрение SAST. Самое простое начало. На один продукт, в pipeline. 1-2 месяца.
4. SCA. Параллельно с SAST или сразу после. 1-2 месяца.
5. Обучение команды. Регулярные сессии, security-чемпионы в каждой команде. Непрерывно.
6. Стандарты безопасного кодирования. OWASP Secure Coding Practices + специфика технологий. 1 месяц.
7. DAST. Развёртывание после SAST/SCA, на тестовых стендах. 2-3 месяца.
8. Масштабирование на все продукты. Постепенное распространение. 6-12 месяцев.

Secure SDLC — это не «галочка в проекте сертификации», а полная перестройка процессов разработки на безопасную основу. Для команд, разрабатывающих ПО для КИИ, государственных систем или критичных коммерческих заказчиков, это обязательное условие конкурентоспособности и регуляторного соответствия. Срок внедрения — 6-12 месяцев, бюджет — 2-6 млн ₽ для типовой команды, окупаемость — через готовность к сертификации ФСТЭК, снижение рисков инцидентов и ускорение release-цикла. Подробнее про общий контекст — в наших статьях про защиту КИИ и требования ФСТЭК.