Масштабирование DevSecOps: управление безопасностью сотен репозиториев

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

1. Команды выбирают разные сканеры и версии, а целые классы проверок (поиск секретов, анализ инфраструктуры как кода, композиционный анализ) незаметно выпадают из процесса или внедряются частично.

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

3. Решения — в переписке. Передача дистрибутивов и исключения для DevSecOps-инструментов согласуются в чатах или иных системах, где могут быть не настроены интеграции с существующими процессами, отсутствует история, а причины и результаты триажа со временем приходится разбирать заново.

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

К примеру, ГОСТ Р 56939-2024 требует интегрировать процессы безопасной разработки с системами среды разработки «в целях обеспечения регулярности и своевременности проверок кода, прослеживаемости устранения выявленных ошибок» (п. 4.13). Для сотен по-разному настроенных конвейеров вручную это, по нашему опыту, почти невыполнимо.

Решение, с одной стороны, довольно простое и давно себя зарекомендовавшее — в частности, в ранее упомянутом ГОСТ Р 56939-2024 по РБПО: рассматривать безопасность не как отдельную надстройку, а как неотъемлемую часть всего жизненного цикла продукта и поставки. Этот цикл — набор компонентов DevOps + AppSec + SecOps, в каждый из которых безопасность встроена изначально. Команды собирают свои процессы из готовых компонентов — сборки, создания образов, деплоя — и автоматически получают проверки, учёт находок и обратную связь. Масштабировать приходится не число сканеров или инструментов, а сам процесс, обеспечивая его единообразие.

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

1. Шаблонизация. Всё, что повторяется в сотнях конвейеров, описано один раз: базовые шаблоны этапов жизненного цикла, модули инструментов и механизм, который собирает из них процесс под продукт

2. Унификация. По умолчанию для всех продуктов одинаковы набор проверок, модель находки, логика контрольной точки безопасности (security gate — автоматического критерия допуска к развёртыванию) и отчёт в запросе на слияние (merge request) со сводной информацией по всем проверкам в рамках pipeline для команды разработки

3. Централизация. Шаблоны, версии инструментов, правила запуска и политики хранятся в центральных репозиториях и меняются в одном месте. Это позволяет как разработчикам, так и DevOps- и DevSecOps-специалистам дополнять или обновлять компоненты и, что не менее важно, делиться компетенциями и практиками между отдельными командами и специалистами.

4. Декларативность. Принцип «всё как код» (everything as code) означает, что любой элемент процесса разработки — сборки, анализ кода, шаблоны, компоненты, проверки безопасности, политики AppSec, Security Gate и документация — существует как декларативное описание в Git, а не как конфигурация, созданная вручную и хранящаяся в разных системах.

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

Как и любой процесс, внедрение стоит начинать поэтапно. Начать можно с использования каталога компонентов (к примеру, через встроенные возможности GitLab), сгруппированных по этапам жизненного цикла, в каждый из которых встроена безопасность:

— Сборка. Разработать компоненты сборки, которые охватывают основные фреймворки и типовые продукты/сервисы. Разработчик подключает компонент сборки под свой стек — и получает проверки кода «из коробки»: статический анализ (SAST), поиск секретов, анализ зависимостей и инфраструктуры как кода, автоматическое построение перечня программных компонентов (SBOM). Дополнительно подключать ничего не нужно.

— Образы. Разработать компоненты сборки образов, которые встраивают сканирование в сам процесс: каждый собранный образ проверяется на уязвимости (SCA и анализ содержимого образа) до того, как попадает в реестр. Для основных сервисов и базовых образов подготовить golden-образы — эталонные образы, которые централизованно обновляются и сканируются. Продукты наследуются от golden-образов, поэтому устранение уязвимости в базовом образе централизованно улучшает безопасность всех продуктов на нём. Также можно сразу подключить подпись образа для последующей проверки его целостности и передачи пользователю.

— Деплой и эксплуатация. Подготовить компоненты деплоя в Docker/Kubernetes, в которых заранее подключены динамический анализ работающего приложения (DAST), средства runtime security и сбор логов безопасности. DAST проверяет развёрнутый стенд, поэтому его результат относится к версии на стенде: им разумно блокировать следующий этап выпуска — например, перенос в промышленную среду. Runtime security и логирование связывают конвейер с SecOps: то, что не удалось найти статически, обнаруживается в работающей системе и возвращается в тот же реестр находок.

Подобный компонентный подход даёт практические преимущества для последующего масштабирования и ускорения процессов разработки и AppSec.

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

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

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

Отчёты по AppSec-процессу попадают в один реестр находок — систему управления уязвимостями, которая приводит отчёты разных сканеров к одному виду, убирает дубликаты и ведёт учёт статусов. Исключения, принятые риски и пороги фиксируются в отдельном Git-репозитории политик и вносятся через MR, после согласования которого вступают в силу. На выходе стоит контрольная точка безопасности — автоматический этап, который пропускает развёртывание или останавливает его. Правила запуска и обработки результатов в репозитории продукта не хранятся: продукт декларирует цели, центр определяет процесс. Решения о находках оформляются как изменения в отдельном Git-репозитории политик и вступают в силу после согласования MR. Такой подход называют GitOps: система синхронизируется с описанием в Git.

Подход, в котором все процессы поставки — сборки, образы, деплой — существуют как компоненты DevOps + AppSec + SecOps со встроенной безопасностью, позволяет поддерживать несколько сотен репозиториев при небольшой команде AppSec. Разработчики и DevOps получают готовые инструменты и немедленную обратную связь, центр исправляет и улучшает процесс в одном месте, а версионирование даёт возможность развивать инструментарий, не рискуя стабильностью команд.

Автор: Мыськив Иван, начальник отдела противодействия компьютерным атакам и управления уязвимостями информационных систем Digital Design