DevSecOps — это не инструмент, а место проверок
Формулировка «нам нужен DevSecOps» обычно означает «нам нужен сканер». Сканер купят, он найдёт четыре тысячи замечаний, разработка их проигнорирует, и через полгода проект закроют как неудачный. Ошибка не в инструменте: дефекты искали там же, где и раньше — в конце, просто быстрее.
Практический смысл DevSecOps один: проверка выполняется в тот момент, когда её результат ещё дёшево применить. Секрет, найденный в коммите, — это тридцать секунд работы. Тот же секрет, найденный в проде, — ротация ключа, разбор доступа и объяснение с заказчиком. Разница не в качестве поиска, а в моменте.
Карта конвейера: где что проверяется
Каждый класс проверок ловит свой класс дефектов. Понимание, какой этап что закрывает, избавляет от попытки решить всё одним инструментом.
| Этап | Класс проверки | Что находит | Реакция |
|---|---|---|---|
| Коммит, до отправки | Поиск секретов, локальные линтеры | Ключи, пароли, токены в коде и конфигурации | Блокировать: цена исправления минимальна |
| Pull request | SAST на изменённых файлах | Инъекции, небезопасная десериализация, ошибки в работе с криптографией | Блокировать только новые дефекты высокой критичности |
| Сборка | SCA и SBOM | Уязвимые и несовместимые по лицензии зависимости, состав поставки | Блокировать по порогу критичности, остальное — в бэклог |
| Сборка образа | Сканирование контейнера и базового слоя | Уязвимости ОС-пакетов, лишние утилиты, запуск от root | Пересобрать на актуальном базовом образе |
| Инфраструктура как код | Проверка манифестов | Открытые порты, публичные бакеты, привилегированные контейнеры, отсутствие шифрования | Блокировать: правится в том же PR |
| Тестовый контур | DAST, проверка API | Ошибки авторизации, обход бизнес-логики, конфигурация веб-сервера | Заводить дефект в общий трекер разработки |
| Перед релизом | Ручной анализ, пентест | Логические уязвимости, цепочки, которые автоматика не видит | Разбор с архитектором, решение о релизе |
| Эксплуатация | Мониторинг, управление уязвимостями | Новые CVE в уже поставленном, аномалии доступа | Плановая ротация версий, реакция по SLA |
Классы проверок мы разворачиваем в рамках направления DevSecOps и AppSec; эксплуатационная часть — это управление уязвимостями.
Порядок внедрения: от быстрых побед к дорогим
Если разработка уже идёт, вводить всё сразу нельзя — конвейер встанет. Порядок ниже проверен тем, что каждый шаг даёт измеримый результат до начала следующего.
Шаг 1. Инвентаризация (1–2 недели)
Список репозиториев, конвейеров, сред и точек выхода наружу. Кто владелец, что куда деплоится, какие внешние адреса открыты. Без этой карты любая автоматизация покрывает случайное подмножество. Внешнюю часть периметра удобно снимать аудитом внешних активов — регулярно всплывают забытые стенды с боевыми данными.
Шаг 2. Секреты (2–3 недели)
Самая быстрая победа. Поиск секретов включается на всех репозиториях сразу, история сканируется отдельным прогоном, найденные ключи ротируются, хранение переезжает в менеджер секретов. Здесь же наводится порядок в учётных записях самого конвейера: у сборочных агентов почти всегда избыточные права — тема IDM/PAM и управления доступом.
Шаг 3. Состав поставки (3–4 недели)
SCA и SBOM: вы начинаете знать, из чего собран продукт. Это одновременно безопасность, лицензионная чистота и основа для импортозамещения — без состава поставки разговор о технологической независимости беспредметен (импортозамещение и технологическая независимость).
Шаг 4. Анализ кода и динамика (1–2 месяца)
SAST включается в режиме «только новые дефекты», DAST — на тестовом контуре. Здесь же появляются правила блокировки сборки и SLA на исправление. Ручной анализ и пентест подключаются последними: они дороги и осмысленны, когда автоматика уже сняла шум.
Как не задушить разработку
Главная причина провала — поток находок, который невозможно обработать. Работающие приёмы:
- Baseline. Всё, что найдено в первый прогон, фиксируется как известный долг и не блокирует. Блокируют только новые дефекты — те, которых не было в прошлой сборке. Иначе команда получает стоп-кран в первый же день.
- Пороги по критичности, а не по количеству. «Не более 10 замечаний» — бессмысленное правило. «Ни одной новой критичной уязвимости в изменённом коде» — исполнимое.
- SLA на исправление вместо мгновенной блокировки. Критичное — 3 дня, высокое — 14, среднее — в плановый релиз. Просрочка эскалируется, а не останавливает конвейер.
- Один трекер. Дефекты безопасности живут там же, где остальные задачи разработки. Отдельный «реестр уязвимостей» не читает никто, кроме того, кто его ведёт.
- Работа с ложными срабатываниями. У команды должен быть простой способ пометить находку как неприменимую с обоснованием — и это решение должно сохраняться между прогонами. Без этого доверие к инструменту теряется за две недели.
- Безопасник в команде, а не над ней. Security champion внутри команды разработки закрывает 80% вопросов на месте.
Метрики, по которым видно движение
- Покрытие: доля репозиториев и конвейеров с включёнными проверками — самый честный показатель на первом году.
- Время до исправления по классам критичности, отдельно для новых и унаследованных дефектов.
- Доля дефектов, найденных до тестового контура — растёт по мере смещения проверок влево.
- Доля ложных срабатываний — если выше трети, правила нужно настраивать, а не требовать дисциплины.
- Возраст самой старой критичной находки — одна цифра, которая честнее любого дашборда показывает, работает ли SLA.
- Время сборки — проверки не должны превращать десятиминутный конвейер в часовой, иначе их начнут отключать.
Российский контекст
- ГОСТ Р 56939 «Разработка безопасного программного обеспечения» задаёт рамку процессов: анализ требований к безопасности, моделирование угроз, статический анализ, тестирование, управление конфигурацией. Для многих заказчиков соответствие этому стандарту — условие приёмки.
- Значимые объекты КИИ. Если ПО работает в контуре значимого объекта, к процессу разработки добавляются требования по 187-ФЗ — см. «Защита КИИ / 187-ФЗ».
- Реестр российского ПО. Для включения нужен подтверждённый состав поставки и контроль зависимостей — то, что даёт SBOM из шага 3.
- Персональные данные в тестовых средах. Копия боевой базы на стенде — типовое и грубое нарушение 152-ФЗ. Решается маскированием и обезличиванием, а не запретом на тестирование.
Чек-лист первых 90 дней
Дни 1–30
- Составлен реестр репозиториев, конвейеров и сред с владельцами.
- Поиск секретов включён на всех репозиториях, история просканирована.
- Найденные ключи ротированы, хранение переехало в менеджер секретов.
- Права сборочных агентов пересмотрены и урезаны.
Дни 31–60
- SCA работает на каждой сборке, SBOM сохраняется как артефакт релиза.
- Определены пороги блокировки по критичности и зафиксирован baseline.
- Дефекты безопасности заводятся в общий трекер разработки.
- Согласованы SLA на исправление и порядок эскалации.
Дни 61–90
- SAST включён в режиме «только новые дефекты» на ключевых репозиториях.
- Сканирование контейнеров и проверка инфраструктурных манифестов встроены в конвейер.
- DAST работает на тестовом контуре хотя бы для внешних сервисов.
- Назначены security champions, собрана первая сводка по метрикам.
Где мы подключаемся
Практика РЕСТАРТ закрывает и построение процесса, и его эксплуатацию:
- DevSecOps и AppSec — проектирование конвейера проверок, настройка правил, работа с потоком находок.
- DevOps, DevSecOps и сопровождение — если нужна не разовая настройка, а команда, которая ведёт конвейер дальше.
- Управление уязвимостями и пентест — эксплуатационный контур и независимая проверка.
- Лаборатория ИБ — разбор сложных находок и проверка гипотез на стенде.
- Private Dev AI — если хочется ускорить разработку AI-ассистентом, не вынося код наружу; как выстраивать вокруг него контроль, разобрано в материале про безопасный корпоративный AI.
Нужен разбор конкретного конвейера, а не общая схема — напишите нам.
Обсудим ваш контур
Опишите задачу, текущие системы, ограничения и ожидаемый результат. Мы предложим первый практичный шаг: диагностику, пилот, аудит, дорожную карту или проектную команду.
