Информационная безопасность в DevOps: от методологии к DevSecOps

DevOps ускорил релизы. Вместе со скоростью выросли и риски: безопасность часто оставалась «послесловием» — дорого, медленно и не успевает за конвейером. Ответ — DevSecOps: защита в каждом этапе жизненного цикла, а не только перед продом.

Связанные заметки: DevSecOps и цепочка поставок, Docker и безопасность.

Зачем это вообще

По данным МВД, число преступлений с использованием ИТ выросло примерно в 2,3 раза за пять лет: с ~294 тыс. в 2019-м до ~677 тыс. в 2023-м; в 2024-м показатель уже около 765 тыс. В 2023-м на цифровые преступления приходилось около трети всех зарегистрированных.

По Роскомнадзору, в 2024 году зафиксировано 135 случаев распространения баз с персональными данными — в сумме более 710 млн записей о россиянах (это объём строк в утёкших базах, а не число уникальных людей; крупная часть пришлась на один инцидент).

Традиционный «пентест в конце» не масштабируется под ежедневные деплои. Нужны автоматические проверки в CI/CD и культура общей ответственности.

По исследованию State of DevOps Russia 2025 («Экспресс 42» / Флант при участии Positive Technologies и других партнёров, >3300 респондентов):

• ~77% используют инструменты ИБ и выстраивают процессы безопасной разработки;
• ~67% уже встроили ИБ-инструменты в CI/CD;
• ~40% заявляют, что безопасность проходит через весь цикл (от планирования до эксплуатации);
• ~75% собирают метрики информационной безопасности.

Что такое DevSecOps на практике

Это не «два сканера в пайплайне». Это смена модели:

1. Shift Left — проверки как можно раньше (IDE, pre-commit, PR), пока цена фикса минимальна.
2. Security as Code — политики и правила в Git, версионируются и ревьюятся как код.
3. Автоматизация — SAST/SCA/secrets/IaC/image scan на каждом коммите или MR.
4. Контекстная приоритизация — CRITICAL в prod ≠ MEDIUM в песочнице; учитывайте публичность и наличие эксплойта.
5. Runtime — мониторинг, алерты, реагирование после деплоя.
6. Общая ответственность — разработчики знают secure coding, ИБ понимает пайплайн.

Типичные угрозы в DevOps-среде

Особенно больно в Kubernetes: сеть, RBAC, secrets, admission — любая «дырка» масштабируется на весь кластер.

Как встроить защиту в CI/CD

Минимальный контур, который имеет смысл почти везде:

IDE / pre-commit → MR (SAST, secrets, SCA)
        → build → image scan + SBOM
        → gate (блок CRITICAL)
        → deploy (GitOps)
        → runtime (логи, метрики, IDS/SIEM)

Планирование и код: линтеры, Semgrep/Sonar в IDE, peer review с чеклистом ИБ, gitleaks в pre-commit.

CI (сборка):

• SAST — Semgrep, SonarQube, GitLab SAST;
• SCA — Trivy fs / OWASP Dependency-Check / Snyk;
• Secrets — gitleaks, detect-secrets;
• IaC — Checkov, tfsec, Trivy config.

Тесты / образ:

trivy image --severity HIGH,CRITICAL myapp:$CI_COMMIT_SHA
trivy image --format cyclonedx -o sbom.json myapp:$CI_COMMIT_SHA

DAST (OWASP ZAP) — на staging, не обязательно на каждый commit.

CD: security gate — при CRITICAL не синкать prod (Argo CD / policy). Опционально: подпись Cosign + проверка на admission.

После деплоя: Loki/ELK + алерты, runtime policies (Kyverno/OPA), SIEM если есть SOC.

Подробнее про SBOM и подпись — в статье про supply chain.

Инструменты (короткий стек)

Выбирайте 3–5 инструментов под стек, а не «всё сразу». Фрагментация — один из главных барьеров зрелости.

Как внедрять без саботажа команды

1. Пилот — один пайплайн, один сервис.
2. Сначала report-only, потом fail на CRITICAL.
3. Документируйте suppressions (.trivyignore) с владельцем и сроком.
4. Уберите долгоживущие ключи → short-lived tokens / OIDC.
5. Ведите SBOM и знайте, из чего собран релиз.
6. Обучение secure coding окупается быстрее, чем очередная лицензия.

Барьеры (State of DevOps Russia 2025)

При использовании инструментов ИБ чаще всего мешают:

• ~46% — нехватка экспертизы у команды внедрения;
• ~42% — совместимость с текущим стеком;
• ~41% — стоимость решений;
• ~27% — непонятные результаты сканирования.

Отсюда практика: меньше «магических» отчётов, больше контекста (какой сервис, какой env, что делать) и общих метрик с разработкой (не только «число CVE»).

Регуляторика (РФ)

С 20 декабря 2024 действует ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» (взамен ГОСТ Р 56939-2016). Это национальный стандарт по безопасной разработке.

Важно: сам по себе ГОСТ не делает DevSecOps обязательным для всех компаний — применение часто добровольное, пока обязанность не закреплена законом, договором, закупочной документацией или отраслевыми требованиями (в т.ч. для процессов сертификации и работы с защищёнными контурами). Для субъектов КИИ и госконтуров ориентир на secure SDLC обычно жёстче — уточняйте актуальные требования ФСТЭК/отрасли у юристов и ИБ, а не копируйте формулировки из блога.

Итог

DevSecOps — не тренд «для галочки», а способ выпускать быстрее и дешевле чинить дыры. Успех зависит не от числа сканеров, а от культуры, Shift Left и понятных гейтов в CI/CD.

Нужен конвейер под ключ или аудит — услуги WeDoOps или Telegram.