Классическая история: релиз намечен на вечер пятницы, за два часа до деплоя выясняется, что в свежем образе контейнера тянется библиотека с критичной уязвимостью, в репозитории лежит .env с токеном от продакшена, а отчёт сканера умеет читать ровно один человек в компании — и он в отпуске. Дальше два сценария: релиз едет с риском или его переносят, а безопасность окончательно превращается в «отдел запретов», который все обходят.
DevSecOps в моём понимании — это не покупка ещё одного сканера и не модная строка в вакансии. Это про то, чтобы проверки жили внутри пайплайна, срабатывали без ручного пинка и выдавали результат, который разработчик может прочитать и починить сам, не заходя в отдельную панель. Ниже — практика: что реально автоматизируется, что нет и в каком порядке это внедрять, чтобы через месяц не отключить всё к чёрту.
Три вопроса, с которых начинается любая автоматизация
Прежде чем тащить в CI очередной инструмент, ответьте на три вопроса по каждому слою защиты:
- Что именно проверяем? Секреты в коде, уязвимые зависимости, небезопасные паттерны кода, конфигурацию инфраструктуры, поведение в рантайме — это разные задачи и разные инструменты.
- Когда проверяем? Чем раньше в пайплайне, тем дешевле исправление. Pre-commit быстрее CI, CI быстрее продакшена, продакшен — это уже инцидент.
- Что делаем с результатом? Если находка не превращается в задачу, которую кто-то закрывает, это не безопасность, а генерация отчётов.
Последний пункт — самый недооценённый. Половина провалов внедрения DevSecOps связана не с тем, что сканер плохо ищет, а с тем, что его находки никто не разбирает.
Слой 1. Секреты: самое дешёвое и самое частое
Если делать один шаг, делайте этот. Утечка ключа доступа — самый частый инцидент в разработке, и он же самый быстрый в обнаружении и предотвращении.
Что работает на практике:
- сканер секретов (gitleaks, trufflehog) в pre-commit и в CI — обязательно с проверкой истории коммитов, а не только текущего diff;
- секрет-менеджер (HashiCorp Vault, облачные secret manager) вместо переменных окружения с долгоживущими ключами;
- короткоживущие токены и OIDC-федерация между CI и облаком вместо статических ключей, которые лежат годами;
- маскирование переменных в логах сборки — «аккуратно» тут не работает, работает «по умолчанию выключено».
Отдельно заведите ритуал: при любом подозрении на утечку ключ ротируется сразу, а не «после разбора». Стоимость ротации — минуты, стоимость разбора последствий — недели.
Слой 2. Зависимости: SCA, SBOM и приоритизация
Сканер зависимостей включить легко — Trivy, Grype, Dependency-Track справятся за вечер. Сложнее другое: на среднем проекте он выдаст несколько сотен «high» за первый же прогон, и это гарантированно убьёт доверие к инструменту.
Поэтому автоматизация строится не вокруг «сколько нашли», а вокруг приоритизации:
- Есть ли исправленная версия? Если фикса нет и обновиться некуда — это задача на компенсирующие меры, а не на «обновите библиотеку».
- Достижима ли уязвимая функция? Если код в уязвимой ветке никогда не вызывается, приоритет резко падает. Reachability-анализ есть не везде, но там, где есть, он экономит десятки часов.
- Есть ли эксплуатация в дикой природе? Оценка CVSS сама по себе мало говорит о риске; EPSS от FIRST и данные из бюллетеней вендоров полезнее, чем голая цифра базового балла.
- Где компонент живёт? Уязвимость в библиотеке на периметре и в библиотеке внутри закрытого контура — разные риски.
Дальше — гигиена supply chain: lock-файлы в репозитории, фиксация версий, приватный прокси-реестр (Nexus, Artifactory) со всеми внешними пакетами и правилами против dependency confusion, проверка на typosquatting. И обязательный артефакт — SBOM в формате CycloneDX или SPDX, который генерируется в пайплайне. Он пригодится ровно в тот день, когда придёт бюллетень про Log4Shell-подобную историю и надо будет за час ответить на вопрос «а у нас вообще это есть?».
Слой 3. SAST, который не бесит разработчиков
Статический анализ — самый спорный слой. Поставленный «как есть», он даёт поток ложных срабатываний, и через две недели его отключают по коллективному требованию. Правила, которые у меня сработали:
- включать не весь набор правил, а только релевантные стеку проекта, начиная с каталога безопасности фреймворка;
- первый месяц работать в режиме предупреждения, собирая статистику, а не блокируя сборки;
- писать кастомные правила под свои грабли — забытый отключённый TLS-verify, конкатенация в SQL, выключенная авторизация в новом эндпоинте. Semgrep и CodeQL это позволяют;
- дублировать ключевые проверки в pre-commit, чтобы разработчик получал обратную связь за секунды, а не через двадцать минут после пуша.
Порог блокировки ставьте по конкретным правилам, а не по общему количеству находок. «Сборка падает, если найдено больше N проблем» — это не политика безопасности, это лотерея.
Слой 4. Артефакты и контейнеры
Сканирование образов (тот же Trivy) — база, но само по себе оно не мешает выкатить уязвимый образ в кластер. Автоматизация начинается дальше:
- минимальные базовые образы и запуск не от root;
- фиксация по digest, а не по плавающему тегу latest;
- подпись артефактов (Sigstore/cosign) при сборке;
- admission control в Kubernetes (Kyverno или OPA Gatekeeper) с правилом «в кластер попадает только подписанный образ из нашего реестра».
Именно связка «подпись + политика на входе» превращает сканирование из отчёта в реальный контроль. Без неё сканер — просто ещё один дашборд.
Слой 5. Инфраструктура как код
Если Terraform и Kubernetes-манифесты лежат в репозитории, проверять их надо до применения, а не после. Здесь хорошо работают Checkov или Trivy в конфиг-режиме, kube-linter, проверка terraform plan на этапе merge request. Политика-как-код (OPA, Conftest) позволяет описать свои запреты — публичные S3-бакеты, открытые security groups, привилегированные поды — и версионировать их вместе с инфраструктурой.
Плюс отдельная строка в чек-листе: периодический прогон kube-bench и проверка того, что NetworkPolicy не «разрешить всё по умолчанию».
Слой 6. Рантайм: детект раньше блокировки
Всё, что не поймали статикой, ловится в работе. Falco или eBPF-инструменты дают события на подозрительное поведение (шелл внутри контейнера, обращение к облачным метаданным, запись в системные директории), аудит-логи Kubernetes дают след, WAF — попытки эксплуатации на периметре.
Порядок зрелости здесь жёсткий: сначала детект и наблюдаемость, потом блокировка. WAF, включённый сразу в блокирующем режиме без настройки, — верный способ уронить легитимный трафик и получить запрет на любые дальнейшие инициативы по безопасности.
Главная проблема — не инструменты, а поток алертов
Шесть слоёв выше дадут вам столько находок, что их физически некому разбирать. Поэтому автоматизация должна включать в себя и работу с шумом:
- единая точка входа для находок — трекер задач или дефектов, а не шесть разных панелей;
- дедупликация и baseline: старое не должно всплывать заново при каждой сборке;
- SLA на исправление по уровням критичности, согласованные с разработкой, а не спущенные сверху;
- файл исключений с обязательным обоснованием и датой пересмотра — иначе все исключения станут вечными;
- метрики: время от появления уязвимости до фикса, доля сборок с проверками, количество открытых критичных находок. Не «сколько всего нашли».
И правило, которое экономит нервы: не блокируйте то, что команда не может починить в тот же день. Блокировка без пути к исправлению — это не безопасность, а простой.
Что автоматизация не закроет
Честный список, чтобы не строить иллюзий:
- Нарушения авторизации. Broken access control — первая категория в OWASP Top 10, и SAST её почти не видит. Проверка «может ли пользователь А получить данные пользователя Б» требует ручных тестов и ревью логики.
- Моделирование угроз. Автоматика не скажет, что в вашей архитектуре защищать нечего, а что — критично.
- Бизнес-логика. Скидочные купоны, накопительные бонусы, лимиты — уязвимости здесь рождаются из требований, а не из кода.
- Нулевые дни и социальная инженерия. Тут выигрывают сегментация, минимальные привилегии и обучение, а не сканер.
Российская специфика, которую стоит держать в голове
Технические проверки и требования регуляторов — не одно и то же. Для ГИС работает приказ ФСТЭК России № 17, для КИИ — 187-ФЗ, для операторов персональных данных — 152-ФЗ, для финансовых организаций — ГОСТ Р 57580. Аттестация и оценка соответствия всё равно идут по требованиям, а не по отчёту вендора.
Практический вывод: зарубежные сканеры, как правило, не имеют сертификации ФСТЭК, но это не мешает использовать их как инструмент внутреннего контроля качества кода — только не стоит выдавать отчёт Semgrep за доказательство соответствия. При выборе инструментов смотрите не на наличие в реестре, а на частоту обновления баз детектов и на то, будет ли вендор поддерживать вас через год. По части вендоров вопрос поддержки и доступности обновлений сейчас открыт, и это стоит проверять до покупки, а не после.
План внедрения: 30 / 60 / 90 дней
- Первые 30 дней: сканер секретов в CI и pre-commit, ротация уже найденных ключей, SCA на pull request в режиме предупреждения, единая точка входа для находок.
- Дни 31–60: SBOM как артефакт сборки, приватный прокси-реестр, сканирование образов, минимальные базовые образы, первые кастомные правила SAST под свой стек.
- Дни 61–90: подпись образов и admission control, IaC-сканирование в merge request, Falco или аналоги в режиме детекта, согласованные SLA на исправление и первые метрики.
Дальше — цикл: измеряете время до фикса, убираете самые шумные правила, добавляете блокировки там, где команда уже стабильно чинит.
Чек-лист, с которым можно идти к тимлиду
- Секреты: сканер в pre-commit и CI, секрет-менеджер, короткоживущие токены.
- Зависимости: SCA в PR, lock-файлы, приватный реестр, SBOM, приоритизация по исправлению и эксплуатации.
- Код: SAST с релевантным набором правил, режим предупреждения на старте, кастомные правила под свои паттерны.
- Артефакты: сканирование образов, non-root, digest-pinning, подпись, admission control.
- Инфраструктура: сканирование IaC, политика-как-код, запрет привилегированных подов и открытых сетей.
- Рантайм: детект до блокировки, аудит-логи, WAF с обкаткой.
- Процесс: одна очередь находок, SLA, файл исключений с датой пересмотра, метрики времени до фикса.
Вывод
Автоматизация защиты информационной системы — это не набор купленных сканеров, а дисциплина: найти проблему раньше, превратить её в понятную задачу, починить в разумный срок и не утопить команду в ложных срабатываниях. Начинайте с секретов и зависимостей — они дают максимум эффекта за минимум усилий. Блокировки включайте последними, когда процесс уже работает. А серебряной пули, которая закроет за вас авторизацию и бизнес-логику, по-прежнему нет — и, судя по всему, не будет.
