Безопасность CI/CD-пайплайна

11 мин чтения·Для руководителя разработки и лидера безопасности

CI/CD-пайплайн — это последняя автоматическая линия защиты перед тем, как код попадёт к пользователям. Каждый коммит, каждый пул-реквест, каждый деплой проходит через него. Это идеальное место для автоматической проверки: уязвимости в коде, опасные зависимости, утечка секретов, небезопасные конфигурации.

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

Почему это важно для компании с разработкой

Масштаб превышает возможности ручной проверки. Небольшая команда может делать десятки коммитов в день. Ни у кого нет времени проверять каждое изменение вручную. Автоматические сканеры закрывают этот пробел.

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

Зависимости — это чужой код. Приложение содержит тысячи строк кода команды и сотни тысяч строк открытых библиотек. Одна уязвимость в стеке зависимостей — и атакующие могут использовать её автоматически. Так произошло с Log4Shell в 2021 году: тысячи организаций были скомпрометированы через одну уязвимую библиотеку.

Атакующие тоже сканируют. Массовая эксплуатация известных уязвимостей — автоматизированный процесс. Российские группы атакующих регулярно сканируют открытые порты и известные CVE в поисках незащищённых систем. Если у вас нет инструментов обнаружения, у атакующих будет преимущество во времени.

Пять типов сканирования

Разные инструменты ловят разные проблемы — они дополняют, а не заменяют друг друга.

Тип	Что делает	Когда запускать
SAST — статический анализ кода	Анализирует исходный код на уязвимости	При каждом коммите / пул-реквесте
SCA — анализ состава ПО	Находит уязвимые зависимости	При каждой сборке
SBOM — реестр компонентов	Ведёт полный перечень всего ПО в продукте	При каждом релизе
IaC-сканирование	Ищет небезопасные конфигурации инфраструктуры	При каждом коммите
DAST — динамическое тестирование	Тестирует работающее приложение	При деплое на стейджинг

SAST — статический анализ кода

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

Что находит: SQL-инъекции, XSS, инъекции команд, небезопасную криптографию, захардкоженные секреты, небезопасную обработку входных данных.

Российские коммерческие инструменты:

• PT Application Inspector (Positive Technologies) — российский SAST, сертифицированный ФСТЭК России. Поддерживает широкий спектр языков. Рекомендован для проектов с требованиями к отечественным средствам защиты информации.
• Solar appScreener (ГК «Солар») — SAST/DAST/SCA в одном продукте. Возможность размещения на собственной инфраструктуре.

Open-source:

• Semgrep — быстрый, настраиваемый сканер с готовыми правилами по OWASP Top 10. Хорошо интегрируется с GitLab CI, GitFlic CI, GitVerse CI.

SCA — анализ состава ПО

SCA-инструменты сканируют файлы зависимостей и находят библиотеки с известными уязвимостями.

Что находит: известные CVE в сторонних библиотеках, устаревшие компоненты без патчей, проблемы с лицензиями.

Российские коммерческие инструменты:

• CodeScoring — российский SCA с реестром уязвимостей, включая данные БДУ ФСТЭК (bdu.fstec.ru). Поддерживает самостоятельное размещение.
• Solar appScreener — включает SCA-модуль.

Open-source:

• Trivy — универсальный сканер: файловые системы, контейнеры, репозитории. Использует несколько баз уязвимостей.
• OWASP Dependency-Check — open-source SCA от OWASP.

SBOM — реестр программных компонентов

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

Зачем это нужно бизнесу:

Скорость реагирования. Когда появляется критичная уязвимость в популярном компоненте, компании с актуальным SBOM узнают за часы, затронуты ли их системы. Без SBOM — тратят дни на ручное исследование.

Видимость цепочки поставок. Ваше приложение зависит от пакета А, который зависит от пакета Б, который зависит от пакета В. Уязвимость в В затрагивает вас — но без SBOM вы можете не знать о существовании В.

Требования заказчиков и регуляторов. Корпоративные клиенты и государственные заказчики всё чаще требуют SBOM как часть оценки безопасности поставщика. В контексте требований Минцифры к составу используемого ПО и реестра российского ПО наличие актуального SBOM — конкурентное преимущество при работе с госсектором.

Форматы SBOM:

• CycloneDX (OWASP) — акцент на безопасности, хорошо интегрируется со сканерами уязвимостей
• SPDX (Linux Foundation) — ориентирован на соответствие лицензий, широко поддерживается

Инструменты:

• Trivy — генерирует SBOM и сразу сканирует на уязвимости
• Syft (open-source, Anchore) — универсальный генератор SBOM
• OWASP Dependency-Track — бесплатная платформа для централизованного хранения и анализа SBOM. Самостоятельное размещение

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

DAST — динамическое тестирование

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

Что находит: отсутствующие заголовки безопасности, активный XSS, неверная конфигурация CORS, проблемы с TLS.

Запускайте только на стейджинге — активное сканирование может нарушить работу продуктивной системы.

Инструменты:

• OWASP ZAP — стандартный open-source DAST. Базовое сканирование: 1–5 минут. Полное: 30–60 минут. Хорошо интегрируется с GitLab CI.
• Solar appScreener — включает DAST-модуль.

Сканирование инфраструктурного кода (IaC)

Если команда использует Terraform или Kubernetes-манифесты для описания инфраструктуры (Yandex Cloud, VK Cloud, Selectel, Cloud.ru), эти файлы тоже нужно сканировать. Небезопасная конфигурация инфраструктуры не менее опасна, чем уязвимость в коде.

Что находит: чрезмерно широкие права доступа, нешифрованные хранилища, открытые сетевые порты.

Инструменты:

• Checkov (open-source) — поддерживает Terraform, Kubernetes, Docker Compose и другие форматы. Имеет готовые правила для облачных платформ.
• Trivy — в режиме сканирования IaC.

Сканирование секретов

Случайно закоммиченные API-ключи, пароли к базам данных, токены доступа — одна из наиболее частых причин инцидентов. Атакующие регулярно сканируют публичные репозитории в поисках таких утечек; внутренние репозитории тоже не застрахованы от случайных коммитов.

Инструменты:

• gitleaks (open-source) — быстрый, настраиваемый сканер Git-истории. Устанавливается как pre-commit хук.
• truffleHog (open-source) — углублённое сканирование, в том числе верификация секретов.

Обнаруженные секреты должны немедленно аннулироваться — даже если коммит был сделан давно и кажется, что «никто не видел». Правильное место хранения секретов — Пассворк (российский менеджер секретов с размещением на собственном сервере) или open-source HashiCorp Vault / OpenBao, но не переменные окружения в репозитории.

Платформы CI/CD для российских команд

Все описанные инструменты интегрируются в CI/CD-пайплайн — запускаются автоматически при каждом изменении кода. Российские команды могут использовать:

• GitFlic (gitflic.ru) — российская платформа с встроенным CI/CD
• GitVerse (gitverse.ru, СберТех) — российская платформа с CI/CD
• GitLab CE, self-hosted — полнофункциональная платформа с GitLab CI; размещение на собственном сервере
• Gitea с внешними CI/CD-инструментами — лёгкая платформа для небольших команд

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

Процесс реагирования на находки

Настроить инструменты — первая часть задачи. Вторая — выстроить процесс работы с их результатами. Без чёткого процесса алерты накапливаются, команда их игнорирует, инструменты отключают «чтобы не мешали».

Приоритизация

Используйте следующую шкалу для расстановки приоритетов:

Приоритет	Признаки	Срок реагирования
Критичный	Активная эксплуатация, CVE с высоким CVSS в БДУ ФСТЭК, данные пользователей под угрозой	1–4 часа
Высокий	Публичный эксплойт, уязвимость в компоненте с внешним доступом	24–48 часов
Средний	Нет публичного эксплойта, ограниченный доступ	Текущий спринт
Низкий	Теоретический риск, нет внешней доступности	Бэклог

Шаги при обнаружении находки

1. Первичная классификация (5–10 минут): установите, что найдено, где находится (конкретный файл, зависимость, компонент), затронут ли продакшн прямо сейчас.

2. Верификация (15–30 минут): не каждый алерт — реальная уязвимость. SAST-инструменты дают ложные срабатывания. Лидер безопасности проверяет контекст: откуда приходят данные, есть ли компенсирующие меры, реально ли уязвимая функция используется в коде.

3. Оценка воздействия: насколько реально эксплуатировать находку в вашем конкретном контексте? Уязвимость в библиотеке, функция которой не вызывается — это другой уровень риска, чем уязвимость в точке входа публичного API.

4. Определение ответа: исправить немедленно, запланировать, задокументировать как принятый риск или подавить как ложное срабатывание (с обязательным обоснованием).

Принятие риска

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

Документ принятия риска должен содержать:

• Идентификатор уязвимости (CVE, идентификатор правила)
• Оценку риска в вашем конкретном контексте
• Компенсирующие меры
• Дату следующего пересмотра
• Подпись ответственного лица (лидер безопасности + руководитель)

Ложные срабатывания

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

Матрица эскалации

Определите заранее, кто принимает решение при разных ситуациях:

Ситуация	Кому эскалировать	Канал
Признаки активной эксплуатации	Технический директор + юрист	Звонок
Критичная уязвимость в продакшне	Руководитель разработки + ТД	VK Teams/eXpress + звонок
Неопределённость с оценкой риска	Старший разработчик или внешний эксперт	Мессенджер
Нужно формальное принятие риска	Руководитель разработки	Письмо с документом
Требуется патч от вендора	Контакт безопасности вендора	Письмо + тикет поддержки

Как предотвратить повторение

После исправления находки важно сделать так, чтобы такая же проблема не появилась снова:

1. Добавьте специфичное правило сканера — если это паттерн в коде команды, добавьте правило Semgrep, которое будет его ловить автоматически
2. Обновите политику зависимостей — заблокируйте уязвимые версии
3. Используйте как обучающий кейс — разберите находку с командой без осуждения конкретного разработчика
4. Улучшите покрытие — если находка была поздней, проверьте, не нужно ли расширить область сканирования

Типичные ошибки

Блокировать всё. Если любая находка блокирует сборку — команда начинает игнорировать результаты или отключать проверки. Блокируйте только критичное и высокое; о среднем предупреждайте без блокировки.

Не блокировать ничего. Сканеры работают в режиме «только отчёт» — находки накапливаются, никто их не разбирает, инструменты превращаются в шум. Определите явные пороги блокировки.

Запускать DAST на продакшне. Активное сканирование может нарушить работу системы. Только стейджинг.

Установить инструменты без процесса. Инструменты нашли проблемы — кто разбирает? Кто принимает решение? Без ответов через месяц всё будет отключено. Назначьте ответственного за тriage находок.

Слишком много инструментов. Пять SAST-сканеров и три SCA — это шум и дублирующиеся находки. Начните с одного инструмента в каждой категории.

Сканировать только основную ветку. Находки обнаружены после слияния — поздно. Сканируйте в каждом пул-реквесте, не только в main.

Рекомендуемый минимальный набор

Проверки встают на разных этапах пути изменения — от коммита до релиза:

Для старта без избыточных затрат — базовый набор на open-source инструментах с возможным дополнением коммерческих российских решений:

Категория	Инструмент	Стоимость
SAST	Semgrep (open-source)	Бесплатно
SAST (с сертификатом ФСТЭК)	PT Application Inspector	Коммерческий
SCA	Trivy (open-source) или CodeScoring	Trivy бесплатен; CodeScoring — коммерческий
Секреты	gitleaks (open-source)	Бесплатно
Контейнеры	Trivy	Бесплатно
IaC	Checkov (open-source)	Бесплатно
SBOM	Trivy + OWASP Dependency-Track	Бесплатно
DAST	OWASP ZAP (open-source)	Бесплатно

Время на настройку базового набора — 8–16 часов работы лидера безопасности. После настройки инструменты работают автоматически при каждом изменении кода.

Если ваша компания работает с государственными заказчиками или подпадает под требования ФСТЭК — рассмотрите PT Application Inspector и Solar appScreener как основные SAST/SCA-инструменты: они сертифицированы и включены в реестр российского ПО.

✓Управленческий чек-лист

• В пайплайне настроен SAST-сканер; критичные находки блокируют слияние пул-реквестов
• Зависимости сканируются автоматически; критичные CVE блокируют деплой
• Git-история и новые коммиты сканируются на наличие секретов
• Для Docker-образов настроено сканирование контейнеров
• SBOM генерируется при каждом релизе и хранится как артефакт сборки
• DAST настроен для стейджинга (не продакшна)
• Определена матрица эскалации: кто разбирает какие находки и в какие сроки
• Задокументирован и согласован процесс принятия рисков
• Регулярные метрики: количество открытых критичных находок, среднее время закрытия
• Назначен ответственный за еженедельный triage алертов

См. также

• Управление секретами — секреты в конвейере
• Безопасность контейнеров и облака — что происходит после сборки
• Требования безопасности — что именно проверять

Что дальше

Вы встроили автоматическое сканирование в процесс разработки. Следующая глава — безопасность контейнеров и облачной инфраструктуры: как защищать Docker-образы, конфигурации в Yandex Cloud / VK Cloud и инфраструктурный код.