На одном из проектов я настраивал CI/CD для финтех-стартапа. Пайплайн работал быстро - 12 минут от коммита до продакшена, разработчики были довольны. Через три месяца внешний аудитор нашёл в приложении захардкоженный API-ключ к платёжному шлюзу, уязвимую зависимость с известным CVE двухлетней давности и открытый эндпоинт без авторизации. Всё это проехало через пайплайн десятки раз - никто даже не проверял. Исправление заняло четыре недели и обошлось в семь раз дороже, чем если бы эти проблемы поймали на этапе сборки. После такого кейса я перестал воспринимать безопасность как "ещё один чеклист перед релизом" и начал прикручивать её прямо в конвейер. Так для меня начался DevSecOps.
DevSecOps vs DevOps - в чём принципиальная разница
DevOps объединяет разработку (Development) и эксплуатацию (Operations) ради одной цели - ускорить доставку кода в продакшен. CI/CD-конвейер автоматизирует сборку, тестирование и деплой. Но в классическом DevOps безопасность остаётся "за дверью": ею занимается выделенная ИБ-команда, которая подключается ближе к релизу или уже после него. Результат предсказуем - уязвимости находят поздно, исправления блокируют релизы, а разработчики воспринимают безопасников как тормоз.DevSecOps - это Development + Security + Operations. Не отдельная фаза, а вшитый в конвейер контроль: безопасность проверяется автоматически на каждом этапе, от первого коммита до работающего сервиса в проде. Если DevOps - конвейер по сборке автомобиля, то DevSecOps - тот же конвейер, но с проверкой тормозов и подушек безопасности на каждой станции, а не только перед выездом из цеха.
| Критерий | DevOps | DevSecOps |
|---|---|---|
| Фокус | Скорость доставки кода | Скорость + безопасность доставки |
| Роль ИБ | Отдельная команда, подключается в конце | Распределённая ответственность на каждом этапе |
| Безопасность в CI/CD | Нет или опционально | Обязательные автоматические проверки |
| Когда находят уязвимости | На этапе тестирования или в проде | На этапе написания и сборки кода |
| Стоимость исправления | Высокая (поздний этап) | Низкая (ранний этап) |
| Соответствие стандартам | Ручные проверки перед аудитом | Автоматическая валидация в пайплайне |
DevSecOps - эволюция DevOps, а не его замена. Всё, что умеет DevOps, остаётся. Добавляется один критический элемент: безопасность как встроенная функция конвейера, а не внешний аудит постфактум.
Принципы DevSecOps
DevSecOps-методология строится на пяти принципах, и каждый закрывает конкретную дыру классического подхода к безопасной разработке ПО.
Shift left - безопасность с первой строки кода
Shift left security - центральный принцип DevSecOps. Идея простая: чем раньше нашёл уязвимость, тем дешевле починить. Баг, который разработчик увидел в IDE до коммита, - минуты работы. Тот же баг, который пентестер раскопал в продакшене, - недели работы нескольких команд.На практике shift left - конкретные инструменты в конкретных точках. Pre-commit хуки, которые не дают закоммитить API-ключ. SAST-сканер (Semgrep, SonarQube), запускающийся при каждом пуше. SCA-анализатор (Snyk, OWASP Dependency-Check), проверяющий зависимости ещё до попадания кода в основную ветку.
Принцип напрямую противодействует атакам на цепочку поставок - Compromise Software Dependencies and Development Tools (T1195.001, Initial Access) и Compromise Software Supply Chain (T1195.002, Initial Access) по классификации MITRE ATT&CK. Если зависимость с вредоносным кодом попадает в проект, SCA-сканер обнаружит известную уязвимость ещё на этапе сборки.
Автоматизация проверок безопасности
Ручные ревью безопасности не масштабируются. Два AppSec-специалиста физически не потянут каждый merge request в проекте с двадцатью разработчиками и десятками коммитов в день. Математика не сходится.Автоматизация встраивает проверки в CI/CD-пайплайн как обязательные стадии: SAST на этапе сборки, SCA при разрешении зависимостей, DAST после деплоя в staging, сканирование IaC-шаблонов перед развёртыванием инфраструктуры. Каждая проверка запускается без участия человека и может заблокировать пайплайн при обнаружении критической проблемы.
Ручные проверки при этом никуда не деваются - threat modeling, архитектурные ревью, пентесты остаются. Но рутину забирает автоматика, а люди фокусируются на задачах, где нужна голова, а не руки.
Коллективная ответственность за безопасность
В традиционной модели "виноваты безопасники" - уязвимость ушла в прод, значит "ИБ не заметили". В DevSecOps безопасность - ответственность каждого. Разработчик пишет код с учётом OWASP-рекомендаций. DevOps-инженер настраивает безопасные конфигурации. Тестировщик включает секьюрити-кейсы в тест-план. ИБ-специалист не блокирует, а помогает: создаёт правила для сканеров, обучает команду, разбирает сложные кейсы.По данным OWASP DevSecOps Maturity Model (DSOMM), зрелая практика DevSecOps включает категорию Culture - именно культурную трансформацию, а не только инструментальную. Без неё инструменты создадут тысячи алертов, которые разработчики будут молча закрывать.
Непрерывный мониторинг и обратная связь
Безопасность не заканчивается после деплоя. Мониторинг отслеживает поведение приложения в рантайме: аномальный трафик, попытки эксплуатации известных уязвимостей (Exploit Public-Facing Application, T1190, Initial Access), несанкционированный доступ к данным.Обратная связь замыкает цикл: если в проде обнаружена новая уязвимость в зависимости, информация автоматически возвращается в пайплайн, и сборки с этой зависимостью блокируются до обновления. Это соответствует модели NIST CSF 2.0, где функция DE (Detect) - анализ аномалий (DE.AE-01) - напрямую связана с функцией RS (Respond) - расследование уведомлений (RS.AN-01).
Compliance as Code
Требования регуляторов - PCI DSS, 152-ФЗ, ГОСТ Р 57580 - закодированы в виде автоматических проверок. Вместо того чтобы собирать доказательства вручную перед аудитом, команда прогоняет проверки при каждом деплое и хранит результаты как артефакты пайплайна.Конкретный пример: политика "в контейнере не должен быть запущен процесс от root" записывается как OPA/Gatekeeper-правило для Kubernetes и проверяется автоматически при каждом деплое. Нарушение - деплой не проходит. Не нужен человек с чеклистом.
Роль ИБ в DevOps - кто за что отвечает
Одна из главных ошибок при внедрении DevSecOps - попытка "назначить одного человека ответственным за безопасность". DevSecOps для начинающих часто подают как "добавьте сканер в пайплайн", но без распределения ролей это не работает.
DevSecOps-инженер - человек на стыке разработки, эксплуатации и безопасности. Настраивает интеграцию SAST/DAST/SCA в пайплайн, пишет политики для OPA, управляет секретами через HashiCorp Vault или аналоги. Не проверяет каждый коммит руками - создаёт автоматику, которая это делает.
Security Champion - разработчик внутри продуктовой команды, прошедший дополнительное обучение по безопасности. Первая линия: ревью кода с фокусом на безопасность, помощь коллегам с алертами от сканеров, участие в threat modeling. Не заменяет AppSec - дополняет.
AppSec-инженер - специалист по безопасности приложений. Проводит threat modeling, настраивает правила SAST под специфику проекта, разбирает сложные уязвимости, которые автоматика не поймала. Работает на уровне нескольких команд, а не одного продукта.
Разработчик - пишет код, следуя стандартам безопасной разработки. Реагирует на алерты сканеров, устраняет уязвимости в своём коде. Не "перебрасывает" проблему безопасникам - исправляет сам, консультируясь с Security Champion или AppSec при необходимости.
Ops/SRE - безопасность инфраструктуры: конфигурация окружений, управление доступами по принципу минимальных привилегий, мониторинг рантайма.
Безопасность в цикле разработки - что происходит на каждом этапе SDLC
Ниже - карта DevSecOps-практик по этапам жизненного цикла, от планирования до эксплуатации. На каждом этапе - конкретные инструменты и техники, а также угрозы по MITRE ATT&CK, которые эти практики нейтрализуют.
Планирование и проектирование
Здесь проводится threat modeling - систематический разбор: что может пойти не так, кто может атаковать, какие компоненты торчат наружу. IriusRisk помогает формализовать процесс, но для начала хватит обычной доски с диаграммой потоков данных.На этом же этапе определяются требования безопасности: какие данные обрабатывает приложение, какие регуляторные требования применимы, какие компоненты критичны. Это соответствует функции GV (Govern) из NIST CSF 2.0 - понимание организационного контекста и управление рисками (GV.OC-01).
Разработка: SAST и pre-commit проверки
На этапе написания кода работает статический анализ - SAST (Static Application Security Testing). Semgrep, SonarQube или Checkmarx анализируют исходный код без его запуска и ловят типовые уязвимости: SQL-инъекции, XSS, небезопасную десериализацию.Pre-commit хуки - ещё один рубеж.
git-secrets или gitleaks перехватывает попытку закоммитить секрет (пароль, токен, приватный ключ) прямо в терминале разработчика. Это критически важная защита от техники Credentials In Files (T1552.001, Credential Access): атакующий, получивший доступ к репозиторию, первым делом ищет захардкоженные секреты.
Bash:
# Установка gitleaks как pre-commit hook
# .pre-commit-config.yaml в корне репозитория
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks:
- id: gitleaksСборка: SCA и проверка зависимостей
На этапе сборки в фокусе - зависимости. Современное приложение на 80-90% состоит из библиотек с открытым исходным кодом. Каждая зависимость - потенциальная точка входа. MITRE ATT&CK выделяет отдельную технику - Compromise Software Dependencies and Development Tools (T1195.001, Initial Access), описывающую именно этот вектор.SCA-инструменты (Software Composition Analysis) - Snyk, OWASP Dependency-Check, Dependency-Track - сканируют дерево зависимостей и сопоставляют версии с базами известных уязвимостей. Критическая уязвимость в транзитивной зависимости, о которой разработчик даже не подозревает, будет обнаружена автоматически.
Тестирование: DAST и интеграционные проверки
DAST (Dynamic Application Security Testing) - проверка работающего приложения снаружи, как это делал бы атакующий. OWASP ZAP - самый распространённый open-source инструмент этого класса. DAST запускается после деплоя в staging и автоматически ищет: открытые эндпоинты без авторизации, кривые заголовки безопасности, уязвимости к инъекциям.DAST дополняет SAST: статический анализ видит потенциальные проблемы в коде, динамический - подтверждает, что проблема реально эксплуатируема в работающем приложении. По отдельности каждый даёт половину картины. Вместе - уже что-то.
Развёртывание: IaC-сканирование и секреты
Инфраструктура как код (Terraform, CloudFormation, Ansible) - стандарт в DevOps. Но IaC-шаблоны могут содержать небезопасные конфигурации: S3-бакет с публичным доступом, security group с открытым0.0.0.0/0 на порт 22, контейнер без ограничений по ресурсам. Я такое видел в продакшене не раз.Checkov или tfsec сканируют IaC-шаблоны до применения и блокируют деплой при нарушениях. Секреты, необходимые приложению в рантайме (пароли БД, API-ключи), доставляются через секрет-менеджер (HashiCorp Vault, AWS Secrets Manager) - никогда через переменные окружения в открытом виде.
Отдельная угроза - Poisoned Pipeline Execution (T1677, Execution): атакующий модифицирует CI/CD-конфигурацию, чтобы внедрить вредоносный код в процесс сборки. Защита - ограничение прав на изменение файлов пайплайна, код-ревью для
.gitlab-ci.yml / Jenkinsfile, подпись артефактов.Эксплуатация: мониторинг и реагирование
После деплоя работает мониторинг рантайма: сбор логов, анализ аномалий, алерты на подозрительное поведение. SIEM-системы агрегируют события, detection-правила выявляют признаки компрометации. Это функция DE (Detect) по NIST CSF 2.0, где DE.AE-01 требует установить baseline нормального поведения и отслеживать отклонения.Обнаруженный инцидент запускает цикл обратной связи: информация возвращается в разработку, уязвимость устраняется, правило для сканера обновляется - и в следующий раз проблему поймают раньше.
Внедрение DevSecOps на практике - минимальный старт
Внедрение DevSecOps не требует закупки enterprise-решений на миллионы. Минимальный работающий пайплайн с проверками безопасности можно собрать за день на open-source инструментах.Требования к окружению
- CI/CD-платформа: GitLab CI, GitHub Actions или Jenkins
- ОС для раннеров: GNU/Linux (Ubuntu 20.04+), минимум 2 ГБ RAM, рекомендуется 4 ГБ
- Docker для запуска сканеров в контейнерах
- Доступ в интернет для загрузки баз уязвимостей (offline-режим возможен с локальными зеркалами, но потребует дополнительной настройки)
Пошаговый минимум
Шаг 1. Добавить pre-commit hook сgitleaks для перехвата секретов (пример выше). Результат: ни один пароль или токен не попадёт в историю репозитория.Шаг 2. Прикрутить стадию SAST в пайплайн. Для GitLab CI с Semgrep:
YAML:
# .gitlab-ci.yml - стадия SAST
sast:
stage: test
image: semgrep/semgrep:latest
script:
- semgrep scan --config auto --error --json
--output semgrep-results.json .
artifacts:
paths: [semgrep-results.json]
allow_failure: false--error - сканер вернёт ненулевой код выхода при обнаружении проблем и сборка упадёт. --config auto подтягивает набор правил под языки проекта.Шаг 3. Добавить SCA-проверку зависимостей. Для Node.js -
npm audit --audit-level=high прямо в пайплайне. Для Python - pip-audit. Универсальный вариант - OWASP Dependency-Check или Trivy: trivy fs --severity HIGH,CRITICAL .Шаг 4. Настроить сканирование IaC-шаблонов:
checkov -d . проверит Terraform/CloudFormation/Kubernetes-манифесты.Шаг 5. Настроить DAST для staging - OWASP ZAP в режиме baseline scan:
zap-baseline.py -t https://staging.example.comКаждый шаг - отдельная стадия в пайплайне. Начните с первых двух: они закрывают наибольшее количество типовых проблем при минимальных затратах.
Преимущества и ограничения DevSecOps
| Преимущества | Ограничения | Когда внедрять | Когда не внедрять |
|---|---|---|---|
| Раннее обнаружение уязвимостей - исправление в 7-10 раз дешевле, чем в продакшене | Увеличение времени сборки на 3-10 минут за счёт сканеров | Продукт обрабатывает персональные данные или финансовую информацию | Прототип или MVP без пользователей, где скорость важнее защиты |
| Автоматическая проверка compliance при каждом деплое | Ложноположительные срабатывания - требуют настройки исключений | Команда использует CI/CD и релизит чаще раза в неделю | Команда из 1-2 человек без CI/CD - сначала нужен DevOps |
| Распределённая ответственность снижает зависимость от ИБ-команды | Требует обучения разработчиков основам AppSec | Регуляторные требования (ФЗ-152, PCI DSS, ГОСТ 57580) | Нет бюджета и времени на обучение - DevSecOps без культуры превращается в "игнорируемые алерты" |
| Защита от атак на цепочку поставок (supply chain attacks) | Alert fatigue - при дефолтной настройке сканеры генерируют сотни малозначительных предупреждений | Используются open-source зависимости (то есть практически всегда) | Проект в стадии legacy-поддержки без активной разработки |
| Культура безопасности повышает зрелость всей команды | Инвестиции в начальную настройку: 40-80 часов DevSecOps-инженера | Команда готова менять процессы и учиться | Руководство не поддерживает изменения - без buy-in сверху внедрение провалится |
Что мешает внедрению - и как с этим справляются
Когда DevSecOps считается "внедрённым"? Не тогда, когда куплена лицензия на Checkmarx. А тогда, когда разработчик, получив алерт от SAST о потенциальной SQL-инъекции, исправляет её сам, без тикета в ИБ-отдел. Это - та самая культура безопасности, которую описывает каждый фреймворк, но которую невозможно купить. Только выстроить.
Я видел команды, которые покупали Fortify за шестизначные суммы в долларах, но не меняли процессы. Результат предсказуем: сканер работал, алерты генерировались, разработчики закрывали их как «won't fix», и через полгода лицензию не продлили. А рядом другая команда - с бесплатным Semgrep и одним мотивированным Security Champion - за те же полгода сократила количество уязвимостей в проде на 60%. Разница не в инструментах.
DevSecOps-методология - это в первую очередь договорённость внутри команды: мы все отвечаем за безопасность, а инструменты помогают эту договорённость соблюдать. Сейчас вижу тренд: компании нанимают "DevSecOps-инженера" и ждут, что один человек закроет все проблемы. Не работает. DevSecOps - не роль, а способ работы. Один инженер настраивает автоматику, но безопасную разработку ПО обеспечивает вся команда. Те, кто понимает это на старте, экономят месяцы разочарований.
Если хотите попробовать прикрутить безопасность к своему пайплайну - начните с gitleaks и Semgrep. Два инструмента, полчаса настройки, ноль затрат. А потом посмотрите, сколько интересного они найдут в вашем репозитории. Гарантирую - будет что обсудить с командой.
Последнее редактирование модератором:
