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

Свежий пример – массовая эксплуатация уязвимостей Microsoft Exchange, о которой мы писали на прошлой неделе. Брешь в одном компоненте открыла доступ к десяткам тысяч серверов. В заказной разработке риски те же: одна непропатченная библиотека или забытый ключ в репозитории и периметр вскрыт.

Что встраивать в пайплайн

Конвейер безопасной разработки собирается из нескольких независимых проверок, и каждая отвечает за свой класс рисков.

  • SAST – статический анализ исходного кода. Ловит инъекции, небезопасную работу с памятью, ошибки авторизации до запуска приложения. Запускается на каждый pull request.
  • SCA – контроль зависимостей. Сверяет сторонние библиотеки с базами известных уязвимостей. Именно здесь чаще всего и прячется проблема: своего кода в проекте 10%, остальное – чужие пакеты.
  • Сканирование секретов. Пароли, токены и приватные ключи не должны попадать в Git. Хук на pre-commit и проверка в пайплайне отсекают утечку до того, как она уйдёт в историю репозитория.
  • Анализ образов контейнеров. Базовый образ тянет за собой уязвимости ОС и системных пакетов. Сканер проверяет образ перед публикацией в реестр.
  • DAST – динамический анализ. Бьёт по уже развёрнутому стенду, имитируя поведение атакующего.

Важно правильно настроить пороги. Жёсткая блокировка сборки на любой находке низкого приоритета приведёт к тому, что команда отключит проверку через неделю. Поэтому критические находки рушат пайплайн, остальное идёт в бэклог с дедлайном.

Организация процесса, а не только инструменты

Инструменты без процесса дают шум. Тысяча предупреждений, которые никто не разбирает, хуже их отсутствия – они создают ложное чувство защищённости. Чтобы DevSecOps работал, нужны три вещи.

Первое – единое окно для находок. Результаты всех сканеров стекаются в один дашборд с приоритизацией и владельцами. Тут логика та же, что и в self-service BI: данные бесполезны, пока их не свели в управляемую картину, по которой принимают решения.

Второе – обучение разработчиков. Сканер показывает проблему, но исправляет её человек. Без понимания, почему конкатенация в SQL-запросе опасна, правки будут косметическими.

Третье – контроль инфраструктуры и среды. Безопасный код на дырявой платформе беззащитен. Для проектов в госсекторе это ещё и вопрос совместимости с требованиями к импортозамещению, о подходах к которому мы разбирали ранее – реестровое ПО и сертифицированные средства защиты встраиваются в тот же конвейер.

С чего начать

Не пытайтесь развернуть всё сразу. Поставьте сканер зависимостей и поиск секретов – это два самых дешёвых шага с максимальной отдачей. Дальше добавляйте SAST и проверку образов. Прогон должен укладываться в минуты, иначе команда начнёт его обходить.

DevSecOps – не отдельный продукт, а дисциплина: безопасность становится свойством процесса разработки, а не финальной стадией перед релизом. Каждый такой конвейер собирается под конкретный стек заказчика, и защита приложений на всём жизненном цикле разработки держится именно на этой дисциплине.