Словарь угроз · Безопасная разработка

DevSecOps: что это и зачем он нужен

Проверено экспертной редакцией SecRadar · по первоисточникам ФСТЭК / ФСБ / Банка России

DevSecOps — практика встраивания проверок безопасности во все этапы DevOps-конвейера, от написания кода до эксплуатации в проде, вместо отдельного аудита безопасности перед релизом. Материал разбирает принцип shift-left, три базовых принципа DevSecOps, конкретные классы инструментов на каждом этапе CI/CD — SAST, DAST, SCA, IAST, контейнерная безопасность, secrets management — и то, как эта практика соотносится с российскими требованиями к безопасной разработке (РБПО) и ГОСТ Р 56939-2024.

Экспертная редакция SecRadar · как мы проверяем факты → Обновлено 14 июля 2026 · ~8 мин чтения ✓ общепринятая практика ИБ, без вендорной привязки

Кратко

Что это: Встраивание проверок безопасности во все этапы DevOps-конвейера, а не отдельная проверка перед релизом.
Shift-left: Перенос проверок безопасности на как можно более ранний этап — ближе к написанию кода, а не к выпуску.
3 принципа: Безопасность как код, автоматизация проверок в CI/CD, распределённая ответственность разработчиков.
Инструменты: SAST, DAST, SCA, IAST, сканеры контейнеров, secrets management — каждый закрывает свой этап конвейера.
РФ-контекст: Техническая реализация процессов РБПО и ГОСТ Р 56939-2024 (25 процессов безопасной разработки, раздел 5) на практике.

Что такое DevSecOps и shift-left

DevSecOps — это расширение DevOps, при котором проверки безопасности выполняются автоматически на каждом этапе конвейера разработки, а ответственность за них несёт не отдельная служба ИБ в конце цикла, а сама команда разработки. Название складывается из трёх слов — Development (разработка), Security (безопасность), Operations (эксплуатация) — и указывает, что все три дисциплины работают в одном непрерывном процессе, а не последовательно передают задачу друг другу.

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

Shift-left переносит те же проверки как можно ближе к моменту написания кода — в IDE разработчика, в pull request, на этапе сборки, — чтобы разработчик увидел и исправил проблему сразу, пока контекст задачи ещё свежий, а не спустя недели после отдельного аудита безопасности.

DevSecOps — не отдельный инструмент и не новая методология разработки, а способ организации уже существующего DevOps-конвейера: те же практики непрерывной интеграции и поставки (CI/CD), но с обязательными автоматическими проверками безопасности на каждом шаге, а не только в момент приёмочного тестирования.

оценка формулировка принципа shift-left — редакционное изложение общепринятой в индустрии практики (OWASP DevSecOps Guideline), не дословная цитата конкретного стандарта

Принципы DevSecOps

DevSecOps держится на трёх принципах: безопасность как код, автоматизация проверок в CI/CD и распределённая ответственность разработчиков за результат. Ни один из них не работает по отдельности — без автоматизации «безопасность как код» превращается в очередной ручной чек-лист, а без ответственности разработчиков автоматические находки просто копятся в бэклоге необработанными.

Принцип 1

Безопасность как код. Политики и правила безопасности описываются в виде конфигураций и скриптов, которые хранятся вместе с кодом приложения в системе версионирования, — так же, как инфраструктура описывается через Infrastructure as Code. Это делает проверки воспроизводимыми и убирает ручную настройку сканера под каждый новый проект.

Принцип 2

Автоматизация в CI/CD. Сканеры безопасности запускаются автоматически на каждый коммит или pull request — без ручного триггера со стороны инженера ИБ. Найденная уязвимость блокирует сборку (gate) или заводит задачу в трекере команды, но не требует, чтобы кто-то отдельно вспомнил о проверке.

Принцип 3

Ответственность разработчиков. Разработчик читает и исправляет находки сканера сам, без передачи задачи отдельной команде ИБ, — служба безопасности задаёт правила и владеет инструментами, но не встаёт узким местом между коммитом и релизом каждой строки кода.

оценка формулировка трёх принципов — редакционная систематизация общепринятой в индустрии практики DevSecOps, не дословная цитата одного источника

Инструменты по этапам CI/CD

У DevSecOps нет одного универсального инструмента — на каждом этапе конвейера, от написания кода до эксплуатации в проде, работает свой класс сканеров, а результаты сводятся воедино отдельной оркестрирующей платформой. Базовый набор классов инструментов и этап конвейера, который каждый из них закрывает, — в таблице ниже.

↔ таблицу можно прокрутить вбок

Этап CI/CD	Класс инструмента	Что делает
Написание кода	Secrets scanning	Ищет пароли, токены и ключи доступа, случайно оставленные прямо в коде или конфигах, — до того как коммит уйдёт в общий репозиторий.
Сборка / статический анализ	SAST	Сканирует исходный код без его выполнения и находит уязвимости в логике приложения — SQL-инъекции, небезопасную десериализацию, ошибки обработки ввода.
Сборка	SCA (Software Composition Analysis)	Анализирует состав open-source зависимостей — библиотек и пакетов — на известные уязвимости (CVE) и лицензионные риски, которых в собственном коде приложения нет.
Тестирование	DAST	Тестирует уже запущенное приложение методом «чёрного ящика», имитируя HTTP(S)-запросы реального пользователя или атакующего, без доступа к исходному коду.
Тестирование	IAST	Работает как агент внутри запущенного приложения во время функционального тестирования — сочетает видимость кода изнутри (как SAST) с реальным трафиком тестов (как DAST), снижая долю ложных срабатываний.
Упаковка / деплой	Безопасность контейнеров	Сканирует образы контейнеров и манифесты на уязвимости в базовых слоях и неверные конфигурации — до того как образ уедет в кластер.
Сквозной этап	Secrets management	Хранит и ротирует пароли, ключи API и сертификаты отдельно от кода и конфигов приложения, выдавая их сервисам динамически во время выполнения.
Сквозной этап	ASOC	Собирает находки всех сканеров конвейера в единый список, убирает дубли, приоритизирует по критичности и автоматически заводит задачи в трекере команды разработки.

факт назначение классов SAST/DAST/ASOC — секция «SAST» и «DAST» словаря SecRadar, /klass/sast/, /klass/dast/, /klass/asoc/ оценка распределение классов инструментов по этапам конвейера — редакционная систематизация распространённой практики DevSecOps (OWASP DevSecOps Guideline), не цитата конкретного стандарта

DevSecOps и РБПО/ГОСТ 56939 в РФ

В России DevSecOps на практике служит технической реализацией требований разработки безопасного программного обеспечения (РБПО), которые описывает ГОСТ Р 56939-2024, — стандарт задаёт 25 процессов безопасной разработки (раздел 5), а инструменты DevSecOps закрывают их автоматизированными проверками внутри CI/CD. ГОСТ Р 56939-2024 введён приказом Росстандарта № 1504-ст от 24.10.2024 и действует с 20.12.2024, заменив редакцию 2016 года.

Сам ГОСТ добровольный, но обязателен «по ссылке» — при сертификации процессов РБПО по приказу ФСТЭК №240, где порядок сертификации прямо ссылается на ГОСТ Р 56939. При сертификации СЗИ по уровням доверия по приказу ФСТЭК №76 связь содержательная, а не текстуальная: прямой ссылки на номер ГОСТа в открытой публичной выписке приказа №76 нет, но на всех открытых уровнях доверия требуется документация по безопасной разработке средства, и на практике её выстраивают по ГОСТ Р 56939.

Раздел 5 ГОСТа перечисляет 25 процессов — от планирования и моделирования угроз, статического/динамического анализа до реагирования на уязвимости и вывода ПО из эксплуатации, — то есть охватывает практически весь конвейер, разобранный выше по этапам DevSecOps. Подробный разбор требований, статуса обязательности и связи с сертификацией ФСТЭК — на отдельной странице РБПО и ГОСТ Р 56939; там же — какие процессы стандарта относятся к управлению уязвимостями после релиза продукта.

факт дата введения ГОСТ Р 56939-2024, приказ Росстандарта № 1504-ст от 24.10.2024, 25 процессов в разделе 5 (5.1–5.25) — сверено по официальному тексту стандарта, /komplaens/rbpo/ факт обязательность «по ссылке» через приказ ФСТЭК №240 — /komplaens/rbpo/ оценка содержательная (не текстуальная) связь с приказом ФСТЭК №76 — прямой ссылки на номер ГОСТа в открытой выписке приказа №76 нет, /komplaens/rbpo/ оценка сопоставление процессов ГОСТа с этапами DevSecOps-конвейера — редакционная интерпретация, не дословная формулировка стандарта

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

DevSecOps что это простыми словами?

DevSecOps — это подход, при котором проверки безопасности встроены в конвейер разработки и выполняются автоматически на каждом этапе, а не отдельной командой в самом конце перед релизом. Уязвимость находят и чинят там же, где написали код, — обычно за минуты, а не спустя недели после отдельного аудита. Метка: оценка — раздел «Что такое DevSecOps и shift-left» выше.

Что значит shift-left в DevSecOps?

Shift-left («сдвиг влево») — принцип переноса проверок безопасности на как можно более ранний этап конвейера, ближе к моменту написания кода, а не к моменту его выпуска в продакшен. Чем раньше найдена уязвимость, тем дешевле её устранить: правка в IDE обходится в разы дешевле, чем патч уже выпущенного продукта. Метка: оценка — раздел «Что такое DevSecOps и shift-left» выше.

Какие инструменты входят в DevSecOps?

Базовый набор — SAST (статический анализ кода), DAST (анализ работающего приложения), SCA (анализ open-source зависимостей на уязвимости), IAST (гибрид SAST и DAST при функциональном тестировании), сканеры контейнеров и secrets management. ASOC связывает результаты всех сканеров в единый конвейер и убирает дубли находок. Метка: факт/оценка — раздел «Инструменты по этапам CI/CD» выше.

Чем DevSecOps отличается от DevOps?

DevOps объединяет разработку и эксплуатацию, чтобы быстрее выпускать код; DevSecOps добавляет к этой связке безопасность как равноправного участника, а не барьер перед релизом. Формально DevSecOps не новая методология, а расширение DevOps: те же принципы автоматизации и непрерывной поставки, но с обязательными проверками безопасности на каждом шаге конвейера. Метка: оценка — раздел «Что такое DevSecOps и shift-left» выше.

Как DevSecOps связан с РБПО и ГОСТ Р 56939 в России?

ГОСТ Р 56939-2024 описывает 25 процессов разработки безопасного программного обеспечения (РБПО) в разделе 5 — от планирования и моделирования угроз до вывода ПО из эксплуатации, — и DevSecOps на практике служит технической реализацией этих процессов в CI/CD. Сам ГОСТ добровольный, но обязателен «по ссылке» при сертификации процессов РБПО (приказ ФСТЭК №240) и содержательно — при сертификации СЗИ по уровням доверия (приказ №76), где прямой ссылки на номер ГОСТа в тексте приказа нет, но требуется документация по безопасной разработке. Метка: факт — раздел «DevSecOps и РБПО/ГОСТ 56939 в РФ» выше.

В чём разница между SAST, DAST и SCA?

SAST сканирует исходный код без его выполнения и находит уязвимости в собственной логике приложения. DAST тестирует уже запущенное приложение методом чёрного ящика, имитируя запросы реального пользователя. SCA проверяет не код приложения, а его open-source зависимости — библиотеки и пакеты — на известные CVE и лицензионные риски. Три класса закрывают разные слои и обычно используются вместе, а не как замена друг другу. Метка: факт — раздел «Инструменты по этапам CI/CD» выше.

Словарь угроз на SecRadar

Разбор терминов и практик безопасной разработки без вендорной привязки — что стоит за понятием, как оно связано со смежными классами СЗИ и какие требования регуляторов за ним стоят.

Открыть словарь угроз →