DevSecOps · 6 мин чтения · Учебная команда Log Academy
Как встроить безопасность в CI/CD-пайплайн
Безопасность CI/CD — это автоматические проверки, встроенные в каждый этап пайплайна поставки. Практичный порядок такой: сначала secret scanning, затем анализ зависимостей (SCA), затем SAST, после этого минимизация и подпись контейнерного образа и, наконец, admission-политики в Kubernetes. Главное условие: результат каждой проверки должен быть понятным, объяснимым и исправимым.
- Сам пайплайн — цель атаки: в нём хранятся секреты, права на деплой в прод и выпускаемые артефакты.
- Добавляйте проверки от дешёвых к дорогим: secret scanning, SCA, SAST, затем контейнеры и Kubernetes.
- Не блокируйте всё с первого дня: сначала режим наблюдения, потом блок только для новых критичных находок.
- Подписанный образ и admission-политика работают в паре: в кластер попадает только то, что собрал ваш пайплайн.
- У каждого исключения должны быть владелец, причина и срок действия.
- SLSA и NIST SSDF дают общий язык, чтобы объяснить, что и где проверяется.
Что такое безопасность CI/CD и почему сам пайплайн становится целью?
Эта работа состоит из двух частей: проверять код, который выпускает пайплайн, и защищать сам пайплайн. О второй части часто забывают. А ведь на build-сервере лежат облачные ключи, пароли от registry и права на деплой в продакшн. Для атакующего это цель привлекательнее, чем само приложение.
Список OWASP Top 10 рисков для CI/CD хорошо показывает картину: слабый контроль потока изменений, злоупотребление цепочкой зависимостей, отравленное выполнение пайплайна (poisoned pipeline execution), плохая гигиена секретов и отсутствие проверки целостности артефактов. То есть безопасность пайплайна — это не установка одного сканера, а защита всей цепочки поставки ПО (supply chain). В этом смысле она неотделима от современной кибербезопасности.
В каком порядке добавлять проверки безопасности?
Самая частая ошибка — подключить все инструменты за один день. Сотни старых находок всплывают разом, сборка краснеет, и команда отключает проверку. Устойчивая безопасность пайплайна строится иначе: начните с дешёвых и точных проверок и двигайтесь поэтапно.
- Secret scanning: находит API-ключи, токены и пароли, попавшие в репозиторий. Самый дешёвый и самый полезный шаг — запускайте его и до коммита (pre-commit hook), и в пайплайне.
- Анализ зависимостей (SCA): показывает известные уязвимости (CVE) и лицензионные риски в используемых библиотеках. Исправление часто сводится к обновлению версии.
- SAST: ищет в вашем собственном коде опасные шаблоны вроде SQL-инъекций и небезопасной десериализации. Шума здесь больше, поэтому начинайте с небольшого набора правил и расширяйте его постепенно.
- Контейнерный образ: минимальный базовый образ, запуск не от root, сканирование образа, SBOM и подпись.
- Admission-политики в Kubernetes: пропускают в кластер только соответствующие правилам и подписанные рабочие нагрузки.
| Проверка | Что ловит | Когда запускается | Типичные инструменты |
|---|---|---|---|
| Secret scanning | Забытые в коде и истории git ключи, токены, пароли | До коммита и при каждом push | Gitleaks, TruffleHog |
| SCA (анализ зависимостей) | Известные уязвимости в библиотеках, лицензионные риски | В каждом merge request и по ежедневному расписанию | Trivy, OWASP Dependency-Check, Dependabot |
| SAST | Опасные шаблоны в вашем собственном коде | В каждом merge request, по изменённым файлам | Semgrep, SonarQube, CodeQL |
| Сканирование и подпись образа | Уязвимости базового образа, неподписанный артефакт | После сборки, до push в registry | Trivy, Grype, Syft, cosign |
| Admission-политика | Неподписанный образ, privileged-контейнер, отсутствие лимитов ресурсов | В момент деплоя в кластер | Kyverno, OPA Gatekeeper, ValidatingAdmissionPolicy |
Важен не инструмент, а порядок. Та же логика одинаково работает в GitLab CI, GitHub Actions или Jenkins.
Как уменьшить и подписать контейнерный образ?
Чем меньше пакетов в образе, тем меньше уязвимостей найдёт сканер и тем меньше инструментов достанется атакующему. Используйте multi-stage build, чтобы убрать компиляторы из финального образа, выбирайте минимальную или distroless-базу и запускайте контейнер от непривилегированного пользователя. Фиксируйте базовый образ по digest, а не по тегу, чтобы под тем же именем не приехало другое содержимое.
Следующий шаг — подпись. Инструментом cosign из проекта Sigstore образ подписывается после сборки, к нему прикладываются SBOM и сведения о происхождении сборки (provenance). В итоге продакшн может с доказательствами ответить на вопрос: «этот образ действительно собрал наш пайплайн?»
Какие риски закрывают admission-политики в Kubernetes?
Admission controller — это механизм, который проверяет запрос к API-серверу Kubernetes до того, как объект будет сохранён. Validating-проверка отклоняет запрос, нарушающий правила, а mutating может его изменить. Именно здесь проверяется образ, подписанный в пайплайне.
- Разрешайте только подписанные образы из вашего собственного registry.
- Запретите privileged-режим, hostPath и сеть хоста.
- Требуйте лимиты CPU и памяти для каждого контейнера.
- Отклоняйте тег «latest» — принимайте только конкретную версию или digest.
Не включайте политики сразу в режиме блокировки. Сначала запустите их в режиме аудита, посмотрите, какие из текущих нагрузок нарушают правила, исправьте их и только потом переходите к блокировке.
Как триажить находки, чтобы команда не отключала проверки?
Защита пайплайна чаще проваливается по организационным, а не техническим причинам. Проверку, которая блокирует каждую сборку, ничего не объясняет и полна ложных срабатываний, быстро отключают. Это главная точка напряжения между командой информационной безопасности и разработчиками. Процесс триажа снимает эту проблему.
- Создайте baseline: перенесите старые находки в отдельный бэклог, а блокировку применяйте только к новым критичным и высоким.
- Каждая находка должна быть понятной: какой файл, какая строка, чем опасно и как исправить.
- Дайте возможность помечать ложное срабатывание (false positive) прямо в коде с указанием причины — и периодически пересматривайте такие пометки.
- У исключений должны быть владелец и срок; просроченное исключение снова блокирует сборку.
- Для утёкшего секрета правило особое: удалить его из кода недостаточно, ключ нужно немедленно ротировать.
Практическое правило
Проверка должна блокировать сборку только тогда, когда разработчик может прочитать результат и сам всё исправить. Иначе её воспринимают как препятствие и отключают при первой возможности.
Как SLSA и NIST SSDF задают рамку для этой работы?
Инструменты меняются, рамка остаётся. SLSA (Supply-chain Levels for Software Artifacts) описывает надёжность процесса сборки уровнями. В версии 1.0 Build L1 требует наличия сведений о происхождении сборки, L2 — их подписи размещённой (hosted) платформой сборки, а L3 — выполнения сборки в усиленной и изолированной среде.
NIST SP 800-218, Secure Software Development Framework (SSDF), смотрит шире и делит практики на четыре группы: подготовка организации, защита ПО, создание защищённого ПО и реагирование на уязвимости. Если привязать каждую проверку в пайплайне к одной из групп, на аудите будет готовый ответ на вопрос «зачем нужен этот шаг?».
Как мы это делаем в нашей лаборатории
Так мы делаем в лаборатории: каждый студент получает собственную виртуальную машину в лаборатории на базе vSphere и в финальном проекте программы DevSecOps строит защищённый пайплайн с нуля. Проверки добавляются в том же порядке, что и в этой статье: secret scanning, анализ зависимостей, SAST, усиление и подпись образа, затем политики Kubernetes. Проект завершается аудитом собственного пайплайна: что проверяется, какой риск остаётся открытым и почему.
Частые вопросы
- С какой проверки начинать безопасность CI/CD?
- С secret scanning. Это дёшево, ложных срабатываний мало, и проверка ловит самую опасную ошибку — ключ, попавший в репозиторий. Следом идут анализ зависимостей (SCA) и SAST.
- Чем SAST отличается от SCA?
- SAST анализирует код, который написали вы, а SCA сверяет сторонние библиотеки с базами известных уязвимостей. Одно не заменяет другое.
- Когда проверка безопасности должна блокировать сборку?
- Только при новых, понятно описанных критичных и высоких находках. Старые находки переносятся в baseline и исправляются планово; иначе команда отключит проверку.
- Зачем подписывать контейнерный образ?
- Подпись доказывает, что образ собран вашим пайплайном и не изменён после сборки. Вместе с admission-политикой в Kubernetes она не пускает неподписанные образы в кластер.
- Как эти темы изучаются на курсе DevSecOps?
- В Log Academy программа DevSecOps длится 6 месяцев и рассчитана на средний уровень — для разработчиков, DevOps- и системных инженеров. Она начинается с основ Linux, Git и CI, проходит через анализ кода и зависимостей, контейнеры, Kubernetes и IaC и завершается финальным проектом.