DevSecOps для корпоративной разработки: практики CI/CD без тормозов

Какие риски обычно прячутся в CI/CD

Большинство инцидентов в пайплайне начинается не со «взлома кода», а с цепочки поставки. В корпоративной разработке DevSecOps чаще всего упирается в три зоны: зависимости, секреты и сами сборки. Каждая из них может незаметно превратить обычный релиз в канал доставки чужого кода.

Зависимости - главный источник сюрпризов: их много, они быстро меняются, а обновления нередко делают «по привычке». Одна уязвимая библиотека или подмененный пакет в реестре попадает в продукт без единой правки вашего репозитория. Похожая история с контейнерными образами: обновили базовый образ, и вместе с ним приехала CVE или лишний инструмент, который облегчает атаку.

Секреты опасны тем, что утечки обычно происходят тихо. Токен, случайно закоммиченный в репозиторий, пароль в конфиге, ключ в переменной окружения, а иногда и «полезный» вывод в логах - и доступ уходит наружу. Дальше злоумышленник может читать артефакты, пушить изменения, запускать пайплайны или скачивать внутренние пакеты, оставаясь похожим на обычного пользователя.

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

Чаще всего проблемы прячутся в одном из пяти мест: в чрезмерных правах CI-токенов и сервисных аккаунтов, в неконтролируемых версиях зависимостей и базовых образов, в секретах, которые «всплывают» в репозитории, артефактах или логах, в сборке «как получится» без фиксированных входов и проверяемого происхождения, а также в хранении артефактов без контроля доступа и неизменяемости.

«Без замедления» для бизнеса значит, что безопасность не должна превращать каждый релиз в ручную проверку и очередь. Для команды это означает понятные правила, автоматические проверки там, где они реально ловят риск, и предсказуемый процесс. Если найдено опасное, пайплайн либо быстро блокирует выпуск по четкому правилу, либо дает безопасный обходной путь: обновление, патч или временное исключение со сроком действия.

Что именно нужно контролировать в корпоративной разработке

В корпорации безопасность в CI/CD - это не один сканер, а понятные границы: какие активы считаются критичными, кто за них отвечает и какие следы должны оставаться после каждого релиза. Без этого проверки превращаются в спор между командами и тормозят выпуск.

Активы, которые чаще всего «утекают» из поля зрения

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

• репозитории кода и их настройки (ветки, права, обязательные проверки)
• артефакты сборки (бинарники, пакеты, библиотеки) и их происхождение
• контейнерные образы и базовые образы, от которых вы наследуетесь
• конфигурации окружений (CI-пайплайны, Helm/manifest-файлы, параметры деплоя)
• доступы к внешним сервисам: registry, хранилищам, облакам, системам мониторинга

Это особенно важно в больших организациях, где продукт включает несколько команд и компонентов. У системного интегратора, который поставляет решения для госсектора или финансовых организаций, одинаково критичны и код, и образы, и конфигурации развертывания.

Роли и ответственность: кто что решает

Чтобы проверки не конфликтовали с релизом, заранее разделите зоны ответственности. Разработка отвечает за исправление уязвимостей и качество кода. DevOps - за безопасные настройки CI/CD и инфраструктуру сборок. Команда безопасности задает политики (что запрещено, что допускается, как оформляется исключение) и проводит аудит.

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

Баланс «строгость vs скорость» чаще всего нужен в двух местах: в правилах, которые блокируют релиз, и в том, как быстро команда получает ясный ответ, что именно нарушено и как это исправить. Практичное правило: блокировать только то, что несет высокий риск, а остальное переводить в предупреждения с дедлайном на исправление.

Контроль зависимостей: SCA, SBOM и политики допуска

Зависимости - главный источник «тихих» рисков. Даже если ваш код проверен, уязвимость может приехать через библиотеку, образ контейнера или внутренний пакет, который давно никто не обновлял. Задача простая: видеть, что именно вы берете в сборку, и иметь ясные правила, что допускается в релиз.

SCA: что именно проверять

SCA (Software Composition Analysis) стоит применять не только к open source. В крупных компаниях внутренние пакеты часто живут годами и наследуют старые версии зависимостей.

Проверяйте минимум три вещи: известные уязвимости (CVE), лицензии и «свежесть» версий. Полезный прием - фиксировать базовый набор по типам: зависимости приложения, зависимости тестов и зависимости сборки (плагины, раннеры, утилиты). Именно сборочные зависимости часто забывают, хотя они тоже входят в цепочку поставки.

Транзитивные зависимости (которые подтягиваются автоматически) - отдельная боль. Практика, которая работает: считать их такими же важными, как и прямые, и регулярно удалять «забытые» библиотеки. Если зависимости больше не используются, но остаются в манифестах, вы платите за них риском и временем сканирования.

SBOM: зачем нужен и как хранить

SBOM (Software Bill of Materials) отвечает на вопрос: «из чего состоит этот релиз». Он нужен не ради отчета, а чтобы быстро понять, затронуты ли вы новой CVE, и чтобы доказать происхождение компонентов при внутреннем аудите или требованиях заказчика.

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

Политики допуска: правила, исключения и пересмотр

Политики работают, когда они короткие и исполнимые. Базовый набор обычно включает запрет релиза при критических CVE без исключения, контроль лицензий (в том числе запрет отдельных типов для коммерческого ПО), ограничение по «возрасту» зависимости (если не обновлялась N месяцев, нужен план), обязательную фиксацию версий (без плавающих диапазонов) и единый список разрешенных источников (репозитории и реестры).

Исключения неизбежны. Главное - не делать их «навсегда». Хороший процесс выглядит так:

• разработчик создает запрос на исключение с причиной и сроком
• безопасность подтверждает риск и условия (например, компенсирующие меры)
• владелец продукта принимает бизнес-решение (релизить или ждать)
• исключение автоматически истекает и требует пересмотра

Простой пример: команда интеграционного проекта для банка находит критическую CVE в транзитивной библиотеке, но патч выйдет через неделю. Вместо паники вы выпускаете релиз с временным исключением на 7 дней, фиксируете версию, добавляете мониторинг и заранее планируете обновление. Через неделю политика напомнит о пересмотре, и риск не останется «в тени».

Секреты: хранение, сканирование и ротация без боли

Секреты обычно утекают не из-за «слабой криптографии», а из-за привычек. Ключ случайно попал в репозиторий, токен оставили в wiki, пароль прокинули в код через переменную. Важно не только запретить так делать, но и дать людям удобный способ работать правильно.

Начните с простого правила: секреты живут вне кода. Нельзя полагаться на «это же временно». Минимум исключите такие места: репозитории (включая историю коммитов и примеры конфигов), значения в исходниках и конфигурационных файлах, корпоративные wiki, тикеты и чаты, общие папки и заметки «для команды», а также переменные окружения на локальных машинах без контроля и сроков жизни.

Дальше нужен менеджер секретов, а не «таблица с доступами». Он должен поддерживать доступ по ролям, аудит (кто и когда запрашивал секрет) и, по возможности, короткоживущие креденшелы. Это особенно помогает для CI: пайплайн получает токен на короткий срок, делает действие - и токен больше не годится. Тогда утечка лога или переменной не превращается в постоянный доступ.

Сканирование секретов стоит поставить в нескольких точках, иначе утечки будут находиться слишком поздно. Практичный минимум: pre-commit или локальный хук для разработчиков, проверка в MR/PR, сканирование истории по расписанию и проверка логов пайплайна и артефактов (секреты часто «всплывают» именно в выводе).

Ротация и отзыв секретов должны быть процедурой, а не проектом раз в год. Хороший подход: владелец для каждого секрета, срок действия и понятный шаг отзыва. Если сканер нашел токен в коммите, команда должна за 10 минут сделать две вещи: отозвать токен и заменить его новым через менеджер секретов. Потом уже разбираться, почему это произошло.

Не забывайте про разделение окружений. Для dev, test и prod должны быть разные ключи и разные права. Тогда даже если тестовый секрет утечет, он не даст доступа к продуктивным данным. Типичная ошибка: один и тот же API-ключ используется в тесте и в проде. Достаточно один раз залогировать запрос в тестовом пайплайне - и вы фактически публикуете ключ от продакшна.

Безопасная сборка: подпись, происхождение и хранение артефактов

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

Изоляция сборки: меньше сюрпризов

Сборка должна быть предсказуемой. Если раннеры «живут» неделями и на них можно поставить что угодно вручную, контроль теряется: сегодня сборка прошла, завтра тот же пайплайн собрал другой бинарник.

Практичный минимум: чистые раннеры (одноразовые или регулярно пересоздаваемые) и изолированное окружение; минимальные права у job (только то, что нужно для сборки и публикации); запрет «ручных» установок по ситуации и фиксированные версии инструментов; сеть по необходимости (если можно собирать без доступа в интернет - отключайте); разделение ролей, чтобы сборка не имела прав на деплой в прод.

Подпись и происхождение: полезно не только «для галочки»

Подпись артефактов и контейнерных образов дает проверяемый ответ на вопрос «это точно наше?». Это помогает аудиту и снижает риск подмены в цепочке поставки. В идеале проверка подписи включается перед деплоем: неподписанное или подписанное не тем ключом не проходит.

Происхождение (provenance) дополняет подпись: кто запустил пайплайн, в каком CI, из какого репозитория и коммита, с какими параметрами сборки. Тогда при уязвимости или инциденте вы быстро находите все затронутые версии и понимаете, что именно откатывать.

Отдельная точка контроля - базовые образы. Запретите latest и закрепляйте версии (лучше по digest), иначе два одинаковых пайплайна могут собрать разные результаты. Обновления делайте по расписанию и через PR, чтобы изменения были видны и проверяемы.

Артефакты храните в управляемом репозитории: доступ по ролям, неизменяемые теги для релизов и понятные сроки хранения (retention). Для финальных релизов теги и подписи должны быть неизменяемыми, для nightly-сборок можно держать короткий срок хранения, чтобы не копить мусор и случайно не деплоить старое.

Если вы строите инфраструктуру для сборок и хранения в корпоративном дата-центре, зафиксируйте эти правила как политики: сборка либо соответствует им, либо не считается релизной.

Пошаговый план внедрения DevSecOps в CI/CD

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

Начните с карты того, что у вас уже есть. В компании часто десятки пайплайнов: разные команды, разные репозитории, разные окружения. Важно понять, где код попадает в сборку, где берутся зависимости, кто может менять переменные окружения и где публикуются артефакты.

Дальше двигайтесь по этапам, добавляя контроль сначала в режиме наблюдения, а уже потом в режиме блокировки:

• инвентаризация: список пайплайнов, ключевых репозиториев, реестров контейнеров и мест хранения артефактов, плюс роли и доступы
• сканирование зависимостей и секретов в режиме отчетов (без падения сборки), чтобы увидеть реальную картину
• правила блокировки: останавливать релиз только при критических уязвимостях, а для остальных задать сроки исправления и ответственных
• контроль сборки и публикации: подпись артефактов, проверка источника сборки, запрет ручных загрузок в продовые хранилища
• аудит и метрики: сколько находок, где они возникают, сколько времени до исправления; отдельный короткий и проверяемый процесс исключений

Порог блокировки вводите постепенно. Для старта обычно достаточно блокировать только critical, а остальное переводить в план работ с понятным SLA. Это снижает шум и помогает командам не игнорировать отчеты.

Пример: команда, которая готовит серверный образ для госзаказчика, видит новую CVE в библиотеке. Если сканирование встроено, в отчете сразу видно, какая версия уязвима и где она подтянулась. По заранее заданным правилам релиз блокируется только если CVE критическая. Если нет - создается задача с дедлайном и владельцем, и релиз не превращается в пожар.

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

Как не замедлить релизы: режимы сканирования и оптимизация

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

Режимы сканирования без очередей

Быстрые проверки должны идти всегда, тяжелые - только когда это действительно нужно.

• на каждый коммит: быстрый SCA по измененным файлам, базовый поиск секретов, минимальные политики
• на main: более строгие правила и расширенный набор проверок, но с ограничением по времени
• перед релизом: полный прогон (включая SBOM, расширенные правила, проверку лицензий) с жестким fail
• по расписанию (ночью или в выходные): глубокие сканы и переоценка рисков на фоне новых CVE

Так вы уменьшаете среднее время пайплайна, но сохраняете контроль там, где ставка выше всего.

Оптимизация: кэш, дифф и параллельность

Самые дорогие операции в CI/CD часто повторяются зря. Кэшируйте базы уязвимостей и результаты сканов, чтобы не скачивать и не пересчитывать одно и то же для каждой сборки. Для монорепо особенно важен дифф-скан: если поменялась одна библиотека или один сервис, нет смысла прогонять весь репозиторий целиком.

Параллелизация помогает, но ее нужно дозировать. Если одновременно запустить все сканеры на всех проектах, пайплайн начнет «съедать» инфраструктуру, а не ускоряться. Введите лимиты на параллельные задачи и таймауты на проверки, которые не должны блокировать разработку.

Отдельно продумайте градации строгости: на feature-ветках допускайте warning, на main - fail для критических находок, а перед релизом включайте жесткие стоп-критерии. Простой пример: критические CVE блокируют релиз, высокие требуют тикет и срок исправления, средние уходят в бэклог с закрепленным владельцем.

Пример сценария: релиз без паники при найденной CVE

Команда в крупном банке (или госоргане) готовит обновление внутреннего сервиса: небольшие изменения в API и новый модуль для отчетов. Изменение выглядит безопасным, сборка проходит, тесты зеленые. Но в последнем PR разработчик добавил новый пакет, который подтянул транзитивную зависимость с критической CVE.

Пайплайн устроен так, что проверки идут в двух режимах. На быстрых ветках (feature, merge request) сканирование работает как ранний сигнал: сообщает о проблеме, но не ломает работу команды. В релизном контуре (release/tag) правила строже: нельзя выпустить то, что точно нарушает политику.

В реальности это выглядит так:

• в merge request SCA-сканер находит CVE в транзитивной библиотеке и пишет понятный отчет: какая цепочка зависимостей привела к уязвимому пакету и есть ли фикс
• MR не блокируется автоматически, но появляется обязательная задача: подтвердить план исправления до релиза
• при попытке собрать релиз политика уже жесткая: релизный job останавливается, потому что уязвимость критическая и попадает в запрещенный диапазон
• dev-сборки остаются быстрыми: разработчики продолжают работать и не ждут долгих проверок на каждом коммите

Дальше у команды два пути: обновить зависимость (лучший вариант) или оформить временное исключение, если фикс недоступен или требует больше времени, чем до окна релиза. Чтобы это не превращалось в «разрешите пожалуйста», исключение оформляется как короткая запись с минимально достаточными полями: срок действия и дата пересмотра, причина (почему нельзя обновить сейчас), ответственный (владелец риска и контакт), компенсирующие меры (например, отключенный функционал, дополнительная проверка, ограничение доступа), план устранения (версия, тикет, дата).

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

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

Частые ошибки и ловушки при внедрении

Самая частая проблема в том, что безопасность пытаются включить как рубильник: вчера ничего не было, а сегодня все пайплайны падают. В итоге команды начинают обходить проверки, отключать шаги или «чинить» отчеты, а не уязвимости. Лучше работает поэтапный ввод правил с ясным объяснением, зачем они нужны.

1) Блокировать все сразу и получить саботаж

Если сделать сканирование обязательным для каждого коммита, быстро появятся очереди, красные сборки и раздражение. Частая ошибка - единый жесткий порог без учета критичности сервиса.

Практичнее начать с режима наблюдения: собрать результаты, убрать ложные срабатывания, согласовать пороги. И только потом включать блокировки для действительно опасных случаев (например, критические CVE в публично доступных сервисах).

2) Путать секреты с конфигами и раздавать доступ «на всякий случай»

Токены в переменных окружения, в .env, в конфиге репозитория, в чатах, в тикетах - так обычно и происходит утечка. Еще хуже, когда один «универсальный» токен подходит ко всем средам.

Нормальная цель простая: секреты отдельно от конфигов, доступ минимальный, разные ключи для dev, stage и prod, и понятная ротация. Если секрет протек, должно быть ясно, кто меняет его, где, и что при этом ломается.

3) Надеяться на сканер и забывать про базовые образы

Даже хороший сканер не компенсирует «вечный» base image, который не обновляли месяцами. Вы будете видеть одни и те же уязвимости, а команды привыкнут их игнорировать.

Минимальный порядок: обновлять базовые образы по расписанию и фиксировать версии; ограничивать набор разрешенных образов и репозиториев; хранить артефакты и образы так, чтобы было понятно их происхождение; проверять зависимости не только в приложении, но и в контейнере; измерять, сколько времени занимает исправление критичных находок.

4) Не иметь процесса исключений и потом потерять контроль

Исключения будут всегда: уязвимость без патча, неподдерживаемая библиотека, временный фикс. Ошибка - делать исключения «вручную» в чате. Нужны сроки, владелец, причина и автоматическое напоминание. Иначе через квартал «временных» исключений станет десятки.

5) Доверять сборочным агентам без изоляции и аудита

Сборочный агент часто имеет доступ к исходникам, секретам и репозиториям артефактов. Если он общий и плохо контролируется, это удобная точка атаки. Для корпоративной среды, особенно при поставках в госсектор или финансы, важно, чтобы сборки были воспроизводимыми, а доступы к агентам - ограниченными и проверяемыми.

Короткий чеклист и следующие шаги

Полезно закончить работу короткой проверкой: что уже защищено, а где пока только «на словах». Ниже - минимальный набор, который снижает риск и не превращает релиз в бюрократию.

В базовом контуре CI/CD обычно достаточно пяти вещей: автоматическое сканирование зависимостей и поиск секретов на ключевых ветках и перед релизом; понятные пороги блокировки (что останавливает сборку, а что уходит в техдолг с дедлайном); сроки исправления по критичности, которые видны всем; централизованное хранение секретов с доступом по ролям, аудитом и регулярной ротацией; подпись артефактов и защищенное хранилище, где их нельзя подменить.

Ориентир для порогов простой: если команда постоянно «ломает» пайплайн из-за средних замечаний, она начнет отключать проверки. Лучше блокировать только действительно опасные случаи, а остальное вести как обязательные задачи со сроками и ответственными.

Дальше важнее всего не распыляться. Сделайте небольшой пилот, чтобы договоренности стали практикой: выберите один продукт и один тип пайплайна (например, сервис с самым частым релизом); зафиксируйте политики (кто решает про исключения, как оформляется временное разрешение, где оно хранится); настройте отчетность в одном месте, чтобы было видно, что блокировалось, что ушло в работу и что просрочено; проведите короткую «учебную тревогу» на тестовой CVE или утекшем токене; закрепите инфраструктуру - надежные серверы для CI, защищенное хранилище артефактов и регламент поддержки.

Если CI/CD для вас критичен, инфраструктуру стоит строить как производственную систему. На практике это часто упирается в контролируемые серверные платформы, прозрачную цепочку поставок и поддержку. В таких проектах уместно опираться на локального производителя и интегратора уровня GSE.kz (gse.kz): когда железо, системная интеграция и сопровождение собраны в одном контуре, проще выстроить предсказуемые правила для сборок и быстрее восстанавливаться при сбоях.