DevSecOps: с чего начать внедрение — пошаговый план

DevSecOps — это не покупка одного сканера, а изменение процесса: безопасность становится частью каждого этапа разработки. Начинать стоит с оценки зрелости и списка критичных систем, затем закрыть быстрые победы (SCA, секреты, репозиторий артефактов), встроить проверки в CI/CD с мягкими quality gates, обучить людей и измерять результат. Делимся планом, который мы применяем в проектах в Казахстане и Центральной Азии.

Шаг 1. Понять, где вы сейчас

Начните с инвентаризации: сколько у вас приложений и команд, где хранится код, как устроены CI/CD и релизы, какие проверки уже есть. Полезно опираться на модели зрелости: OWASP SAMM (Software Assurance Maturity Model) — открытая рамка, которая помогает оценить текущие практики безопасной разработки, выстроить сбалансированную программу итерациями и измерять прогресс; OWASP DSOMM (DevSecOps Maturity Model) — проект OWASP, ориентированный именно на DevSecOps. Они фиксируют стартовую точку и целевой уровень, чтобы цель не сводилась к фразе «хотим быть безопаснее».

Опорой для требований к процессу может служить NIST SP 800-218 (SSDF) — набор высокоуровневых практик безопасной разработки, опубликованный в феврале 2022 года. Он подходит для любой модели жизненного цикла разработки и даёт заказчикам и поставщикам общий язык для разговора о безопасности.

Шаг 2. Определить риски и приоритеты

Не все приложения одинаково критичны. Интернет-банкинг и внутренняя вики требуют разного уровня контроля. Составьте список критичных систем — по данным, которые они обрабатывают, доступности из интернета и влиянию на бизнес — и начните внедрение с них. Такой список заодно становится основой для бюджета: бюджет внедрения зависит от числа приложений, команд и выбранных инструментов.

Шаг 3. Быстрые победы

• SCA и контроль open-source. Минимум ложных срабатываний, максимум эффекта — см. разницу SAST, DAST и SCA.
• Секреты вне кода. Найдите пароли и токены в репозиториях и перенесите их в хранилище секретов — подробнее о секретах.
• Защищённый репозиторий артефактов с блокировкой вредоносных пакетов.

Эти меры дают заметный эффект за недели, не ломая процессы разработки, и показывают руководству первые результаты.

Шаг 4. Встроить проверки в конвейер

Каждой проверке — своё место:

• Commit / pull request: SAST по изменённому коду, поиск секретов.
• Сборка: SCA, формирование SBOM, сканирование образов контейнеров.
• Тестовый стенд: DAST, FAST для frontend.
• Продакшен: регулярное DAST-сканирование и мониторинг.

Важно с самого начала договориться о quality gates: какие находки блокируют релиз, а какие заводятся задачей. Начинайте мягко — с информирования, ужесточая правила постепенно. Для запланированных сканов DAST хорошо подходит режим по расписанию, например ночной запуск, который требует минимум участия после настройки. Техническая сторона для GitLab разобрана в статье как встроить SAST и SCA в GitLab CI.

Шаг 5. Выбрать инструменты через пилот

Не покупайте инструмент по презентации вендора. Возьмите 3–5 репозиториев разных команд, проверьте кандидатов на одних и тех же данных и оцените долю истинных находок, скорость сканирования и удобство для разработчиков. Как организовать такой тест, описано в статье пилот SAST и SCA за 30 дней.

Шаг 6. Обучить людей

Инструменты бесполезны, если разработчики не понимают результатов. Короткие практические курсы по безопасной разработке и разбору находок окупаются быстрее всего. Мы проводим корпоративное обучение AppSec и DevSecOps. Хорошая практика — выделить в каждой команде разработки «чемпиона безопасности», который первым разбирает находки и помогает коллегам.

Шаг 7. Измерять

• Доля приложений, покрытых проверками
• Среднее время исправления критичных уязвимостей (MTTR)
• Количество уязвимостей, найденных до продакшена vs после
• Доля ложных срабатываний

Метрики нужны не для отчёта ради отчёта: по ним видно, где процесс буксует, и на их основе обосновывается дальнейшее финансирование.

Типичные ошибки

• Купить инструмент и «включить всё» — команда тонет в тысячах находок.
• Блокировать релизы с первого дня — разработка начинает обходить проверки.
• Делать DevSecOps силами только ИБ без участия разработки и DevOps.
• Не назначить владельцев исправления: находки без ответственного не закрываются.

Если нужна карта действий под вашу организацию, её можно получить на странице внедрения DevSecOps.

Роли и ответственность

DevSecOps не работает, пока за безопасность отвечает только один отдел. Практичное распределение выглядит так: служба ИБ определяет политики и требования, анализирует находки высокого риска и контролирует метрики; разработчики исправляют дефекты в своём коде и зависимостях; DevOps-инженеры встраивают проверки в конвейеры и поддерживают инфраструктуру инструментов; владельцы продуктов принимают решения об исключениях и приоритетах. Для крупных организаций с несколькими командами полезно назначить в каждой команде ответственного за безопасность — он становится точкой связи с ИБ.

Как не потерять темп при внедрении

Самый частый сценарий провала — большой проект с отложенным результатом. Внедрение, на которое уходит год до первой пользы, теряет поддержку руководства и энтузиазм команд. Работает обратный подход: короткие итерации по две–четыре недели, в каждой из которых команда получает конкретный видимый результат — найденные и закрытые секреты, заблокированный вредоносный пакет, отчёт по состоянию критичных приложений. После каждой итерации стоит пересматривать приоритеты по метрикам из предыдущего раздела.

Отдельно стоит продумать работу с накопленным техническим долгом по безопасности. Старый код почти всегда содержит сотни находок. Не пытайтесь закрыть всё сразу: зафиксируйте текущее состояние как базовую линию, не допускайте появления новых критичных проблем в изменениях и планомерно сокращайте старый долг в отдельном бэклоге.

Чем DevSecOps отличается от обычного AppSec

Классический подход к безопасности приложений — периодические проверки перед релизом, часто силами внешних специалистов. DevSecOps переносит часть этих проверок в ежедневную работу: автоматические сканирования на каждом изменении, быстрая обратная связь разработчику, единые политики для всех команд. Периодические углублённые проверки не исчезают: пентест критичных систем и экспертный анализ остаются важной частью программы, но теперь они дополняют, а не заменяют постоянный контроль.

Что изменится для разработчиков

Успех зависит от того, как новые проверки ощущаются в ежедневной работе. Находки должны приходить туда, где разработчик уже работает: в pull request, в IDE, в трекер задач. Каждая находка должна содержать понятное описание, место в коде и рекомендацию по исправлению. Сообщения вида «найдено 500 проблем» без контекста вызывают отторжение, а три конкретные находки с готовым способом исправления — действие. Поэтому на старте лучше настроить сканеры строго на критичные классы дефектов и расширять охват по мере того, как команда привыкает.

Важный момент — время. Если проверка в pull request занимает десятки минут, её начнут обходить. Тяжёлые сканирования выносят на ночные запуски или на ветки релиза, а быстрые проверки (поиск секретов, SAST по изменённым файлам, SCA по манифестам) оставляют в основном потоке.

Как обосновать проект перед руководством

Руководству редко интересны названия инструментов. Говорить с ним лучше языком рисков и стоимости: какие системы критичны, что произойдёт при инциденте, какие требования предъявляют регуляторы и заказчики, сколько времени сейчас уходит на ручные проверки перед релизом. Стартовые измерения (покрытие, время исправления, число находок в продакшене) дают точку отсчёта, а динамика метрик через несколько кварталов становится аргументом для продолжения проекта. Подготовьте план из нескольких итераций с понятным результатом в каждой, и обсуждение бюджета станет предметным.

Частые вопросы

Источники

• OWASP SAMM
• OWASP DevSecOps Maturity Model (DSOMM)
• NIST SP 800-218: Secure Software Development Framework (SSDF) v1.1
• OWASP DevSecOps Guideline: DAST