SAST в CI/CD: как настроить проверку кода и Quality Gate
Подключить сканер к конвейеру — первый шаг. Для рабочего процесса нужно ещё решить, какие результаты влияют на выпуск, кто разбирает находки и что происходит при сбое анализа. Ниже — предлагаемый порядок внедрения и приёмочные проверки. Это практическая схема SecRadar, которую нужно адаптировать к рискам и устройству вашей разработки.
Если вы ещё выбираете инструмент, начните с обзора класса SAST и сравнения функций анализаторов. Здесь разбираем процесс внедрения, а не оцениваем продукты.
Определите, что именно должен проверять конвейер
Возьмите несколько проектов, представляющих основные языки, способы сборки и типы приложений. Один маленький репозиторий без зависимостей не покажет, как проверка будет работать на основной кодовой базе.
Для каждого проекта запишите версию языка и компилятора, команды сборки, приватные пакеты, генерируемый код и каталоги, которые анализировать не нужно. Назначьте владельца настройки сканера и ответственного за разбор находок. Согласуйте, где разработчик увидит результат: в IDE, отчёте конвейера или отдельном интерфейсе.
Решите, какие события запускают проверку: запрос на слияние, изменение основной ветки, расписание или подготовка релиза. Это разные сценарии. Например, документация GitLab отдельно оговаривает включение сканирования в merge request pipelines: само подключение security job не гарантирует запуск в каждом нужном типе конвейера. Источник: GitLab Detect.
Первый запуск и baseline
Начните с режима наблюдения, чтобы проверить охват и разобраться с результатами до включения блокировки. Зафиксируйте commit, версию анализатора, правила, настройки и окружение сборки. Без этого повторный отчёт трудно сопоставить с исходным.
Разберите выборку находок вместе с разработчиками и специалистом по безопасности. Разделите подтверждённые проблемы, ложные срабатывания и случаи, где пока недостаточно контекста. Для подавления сохраняйте причину и автора решения; для принятого риска — владельца и срок пересмотра.
Baseline — точка сравнения, а не признание старого кода безопасным. Ранее найденные подтверждённые проблемы остаются в плане устранения. Политика для новых изменений позволяет управлять поступлением новых проблем, но не закрывает накопленный долг.
После обновления правил или анализатора проверьте сопоставление находок. Новое срабатывание может быть следствием нового правила, а не изменения кода. Не обещайте разработчику точное разделение «старое/новое», пока не проверили его на переименовании файла, переносе функции и повторной сборке.
Quality Gate: три результата вместо одного
Разделяйте техническое выполнение анализа и решение о допуске изменения. У конвейера должны различаться как минимум три результата:
| Состояние | Что произошло | Предлагаемое действие |
|---|---|---|
| Проверка пройдена | Анализ завершился, отчёт обработан, запрещённых политикой находок нет | Продолжить процесс |
| Политика нарушена | Есть находки, которые требуют исправления или согласования | Остановить продвижение изменения либо запросить назначенное согласование |
| Проверка не состоялась | Нет отчёта, произошёл тайм-аут, ошибка лицензии или сбой сканера | Показать техническую ошибку; не выдавать её за отсутствие уязвимостей |
Конкретные пороги определяет команда: важность находки, её статус, область кода, новизна и доступность опасного пути. Универсального порога для всех репозиториев нет. Опишите также временные исключения и право их выдачи.
В GitLab политики согласования merge request анализируют отчёты после выполнения CI-проверок. Это отдельный механизм со своими условиями, редакцией и требованиями к защищённым веткам. Не переносите его поведение автоматически на Jenkins, другую редакцию GitLab или встроенный Quality Gate выбранного сканера. Источник: GitLab Merge request approval policies.
Проверьте не только успешный сценарий
До распространения настройки на все проекты выполните одинаковые контрольные сценарии и сохраните результаты:
- Внесите заранее проверенный пример уязвимости в тестовую ветку. Убедитесь, что сканер запускается, находит её и нужный этап действительно блокируется.
- Исправьте пример. Проверьте снятие блокировки и сохранение связи с предыдущей находкой.
- Создайте согласованное исключение. Проверьте автора, причину, срок и поведение после его окончания.
- Остановите анализатор или лишите задание доступа к лицензии. Убедитесь, что ошибка не отображается как успешная проверка безопасности.
- Измените имя файла и перенесите функцию. Проверьте историю и определение новых находок.
- Запустите несколько проверок одновременно. Измерьте очередь, время анализа и потребление ресурсов.
Проводите такие проверки в тестовой среде на коде, который разрешено использовать для испытаний. Сохраните commit, конфигурацию, журнал задания, отчёт и итоговое решение конвейера — по ним будет проще повторить проверку после обновления.
Закрытый контур и доступ к исходникам
Локальная установка сама по себе не подтверждает автономность. Составьте перечень внешних зависимостей: активация лицензии, обновления анализатора и правил, пакеты для сборки, базы зависимостей, внешние модели и отправка диагностических данных.
Определите, где хранятся исходники, отчёты и фрагменты кода, кто их видит и сколько времени они доступны. Для агента конвейера выделите отдельную служебную учётную запись с необходимыми правами. Проверьте журналы доступа и удаление временных данных. Если используется AI-компонент, отдельно согласуйте модель, место её работы и состав передаваемых данных.
Какие метрики собирать после запуска
Считайте долю нужных конвейеров, в которых анализ действительно завершился и отчёт обработан; время ожидания и выполнения; число технических ошибок; время разбора и исправления подтверждённых находок. Ложные срабатывания оценивайте на экспертно размеченной выборке с указанием языка и настроек.
Общее число находок не показывает пользу инструмента само по себе. Его рост может означать расширение охвата или обновление правил. Сравнивайте сопоставимые проекты и объясняйте изменения состава проверки.
Перед покупкой сопоставьте CLI, CI/CD, Quality Gate, историю и права доступа в матрице SAST. Для организации процесса пригодятся материалы о DevSecOps и безопасной разработке. Проверку полноты обнаружения и производительности проводите отдельно по процедурам пилота.