DevSecOps в России: контекст Q2 2025
DevSecOps — интеграция безопасности в жизненный цикл разработки — в России ко второму кварталу 2025 года находится на самом раннем этапе. Если глобально концепция shift-left security обсуждается с 2018 года, и крупные компании прошли путь от «безопасность после релиза» до «безопасность при каждом коммите», то в России этот путь только начинается.
Катализатор — ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения», который в 2025 году из рекомендательного стандарта фактически становится обязательным. ФСТЭК включает требования стандарта в сертификационные критерии для ПО, используемого на объектах КИИ. Это означает: если ваш продукт работает в инфраструктуре субъекта КИИ — вы обязаны выполнять требования ГОСТ к безопасной разработке.
Для большинства российских компаний это новая территория. По оценкам экспертов Positive Technologies и «Солар», 80% российских компаний-разработчиков находятся на уровне зрелости AppSec 0–1 (из 5): безопасность либо отсутствует в процессе разработки, либо сводится к ручному пентесту перед релизом.
ГОСТ Р 56939: от бумаги к практике
ГОСТ Р 56939 определяет требования к процессу разработки безопасного ПО. Стандарт включает:
- Моделирование угроз на этапе проектирования
- Статический анализ кода (SAST) — поиск уязвимостей в исходном коде
- Динамический анализ (DAST) — тестирование работающего приложения
- Анализ состава ПО (SCA) — проверка зависимостей на известные уязвимости
- Фаззинг-тестирование — поиск ошибок обработки входных данных
- Управление уязвимостями — процесс выявления, приоритизации и устранения
На бумаге всё логично. На практике — разрыв между требованиями стандарта и реальными возможностями компаний огромен. Моделирование угроз требует экспертизы, которой нет у большинства разработчиков. SAST-инструменты генерируют сотни false positive, которые никто не разбирает. SCA — вообще нишевая практика: большинство компаний не знают, какие зависимости используют их продукты.
ФСТЭК осознаёт этот разрыв и готовит серию подзаконных актов, которые конкретизируют требования стандарта для разных категорий ПО. В Q2 2025 обсуждаются проекты приказов, детализирующие процедуры сертификации и контроля.
PT AI и Solar appScreener: два полюса рынка
Российский рынок инструментов анализа кода (SAST/DAST/SCA) сформирован вокруг двух основных продуктов: PT Application Inspector (Positive Technologies) и Solar appScreener («Солар»).
PT Application Inspector (PT AI) — наиболее функциональный российский SAST-инструмент. Поддерживает 30+ языков программирования, интегрируется с CI/CD-пайплайнами (Jenkins, GitLab CI, TeamCity), включает базовые возможности DAST и SCA. Основное преимущество — низкий уровень false positive по сравнению с конкурентами. Целевая аудитория — enterprise и компании, работающие с КИИ.
Solar appScreener — второй по рыночной доле инструмент. Сильные стороны — простота внедрения и цена (ниже, чем PT AI). Поддерживает 36 языков и бинарный анализ (можно анализировать скомпилированный код без исходников). Ориентирован на средний бизнес и компании, начинающие внедрение AppSec.
Оба инструмента — российские, включены в реестр отечественного ПО, что критично для КИИ и госсектора. Западные альтернативы (SonarQube, Checkmarx, Snyk) доступны, но формально не могут использоваться на объектах КИИ.
SCA: слепое пятно российского AppSec
Software Composition Analysis (SCA) — анализ open-source-зависимостей на известные уязвимости — остаётся наименее развитой практикой в российском DevSecOps. Это парадокс: 90% современного кода — это зависимости из open-source, но большинство компаний не контролируют их безопасность.
Проблема усугубляется спецификой российского рынка: компании активно используют open-source в рамках импортозамещения (PostgreSQL вместо Oracle, Linux вместо Windows), но не внедряют процессы управления зависимостями. Результат — растущая поверхность атаки, которую никто не мониторит.
Глобально SCA-инструменты (Snyk, Mend, Dependabot) стали стандартом в CI/CD. В России их аналоги только появляются: PT AI включает базовые SCA-функции, CodeScoring от «Профископ» позиционируется как специализированный SCA-инструмент для российского рынка. Но проникновение SCA пока не превышает 5–10% среди компаний-разработчиков.
Уровни зрелости: где находятся российские компании
Зрелость AppSec-практик в российских компаниях можно оценить по пятибалльной шкале (модель BSIMM/OWASP SAMM):
| Уровень | Описание | Доля компаний |
|---|---|---|
| 0 — Отсутствие | Безопасность не интегрирована в разработку | ~40% |
| 1 — Начальный | Ручной пентест перед релизом, эпизодический SAST | ~40% |
| 2 — Управляемый | SAST в CI/CD, базовая политика уязвимостей | ~15% |
| 3 — Оптимизированный | SAST + DAST + SCA, threat modeling, security champions | ~4% |
| 4–5 — Зрелый | Полный DevSecOps, автоматизация, метрики, culture of security | ~1% |
80% компаний на уровнях 0–1 — это не критика, а констатация. Российский рынок AppSec моложе глобального на 3–5 лет. Компании, которые сейчас находятся на уровне 1, при правильных инвестициях могут достичь уровня 2–3 за 12–18 месяцев.
Ключевой блокер перехода — не отсутствие инструментов, а дефицит людей. AppSec-инженер — одна из самых дефицитных специализаций в российском IT. Рынок обучает «разработчиков» и «безопасников» отдельно — специалистов, совмещающих обе компетенции, крайне мало.
Перспективы: ФСТЭК и принудительная зрелость
DevSecOps в России во второй половине 2025 года получит мощный регуляторный импульс. ФСТЭК готовит серию приказов, конкретизирующих требования ГОСТ Р 56939:
- Обязательный SAST для ПО на КИИ: статический анализ кода станет требованием сертификации — без него продукт не попадёт на объекты критической инфраструктуры
- SCA-контроль: компании будут обязаны вести реестр open-source-зависимостей и отслеживать CVE — это создаст спрос на SCA-инструменты
- Аттестация процессов: не только продукт, но и процесс разработки будет подлежать аудиту — это затронет CI/CD-пайплайны, управление доступом к коду, code review
Для компаний-разработчиков это означает: внедрение AppSec — не вопрос «хотим или нет», а вопрос «когда». Компании, начавшие в 2025 году, получат преимущество: они пройдут кривую обучения до того, как требования станут строгими.
Рекомендация для инженерных лидеров — начать с минимума: SAST в CI/CD (PT AI или Solar appScreener), базовый SCA для критических зависимостей, обучение одного-двух «security champions» в каждой команде. Это уровень 2, и он достижим за 6 месяцев с ограниченными инвестициями.
FAQ о DevSecOps Q2 2025
Обязателен ли ГОСТ Р 56939 для разработчиков ПО?
Формально ГОСТ — рекомендательный стандарт. Но ФСТЭК включает его требования в критерии сертификации для ПО, используемого на объектах КИИ. Фактически: если ваш продукт работает в инфраструктуре субъекта КИИ — выполнение требований ГОСТ к безопасной разработке обязательно.
Какие SAST-инструменты доступны в России?
Два основных: PT Application Inspector (Positive Technologies) — наиболее функциональный, с низким уровнем false positive; Solar appScreener («Солар») — проще во внедрении, поддерживает бинарный анализ. Оба включены в реестр отечественного ПО. SonarQube доступен, но не для КИИ.
С чего начать внедрение DevSecOps?
Минимальный старт: SAST в CI/CD-пайплайне (автоматический анализ при каждом merge request), базовый SCA для критических зависимостей, обучение 1–2 «security champions» в каждой команде. Это переводит компанию на уровень зрелости 2 за 6 месяцев. Следующий шаг — DAST, threat modeling и формальная политика уязвимостей.