Когда останавливать пайплайн, а когда только предупреждать

Вы только что добавили сканер безопасности в свой CI-пайплайн. Первый запуск находит 47 проблем. Три помечены как критические, двенадцать — как высокие, остальные — средние и низкие. Теперь нужно принять решение: останавливать пайплайн на каждой находке или пропускать всё и просто собирать отчёты?

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

Ни одна из крайностей не работает. Ответ — порог по критичности.

Критичность показывает, что действительно важно

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

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

Простое правило: останавливать пайплайн на критических и высоких находках. Средние и низкие пропускать с предупреждением.

Дерево решений ниже обобщает это правило:

flowchart TD A[Находка сканера] --> B{Критическая или высокая?} B -->|Да| C[Остановить пайплайн] B -->|Нет| D{Средняя или низкая?} D -->|Да| E[Предупредить, пропустить] D -->|Нет| F[Игнорировать / Инфо]

Почему это работает на практике

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

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

Такой баланс сохраняет полезность пайплайна, не превращая его в узкое место.

Исключения существуют, но для них нужны правила

Простое правило — хорошая отправная точка, но у реальных проектов есть особые случаи.

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

Иногда средняя находка находится в чувствительном компоненте, например, в шифровании или аутентификации. Хотя сканер оценивает её как среднюю, риск выше из-за контекста. Возможно, вы захотите остановить пайплайн именно для этой находки, даже если она не критическая и не высокая.

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

Стройте шлюз качества, а не правило «ноль находок»

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

Лучший шлюз качества оценивает, нарушают ли находки порог риска. Примеры:

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

Эти правила реалистичнее, чем «ноль находок». Они признают, что с одними уязвимостями можно работать, а другие нужно блокировать немедленно.

Как настроить порог

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

Затем добавьте уведомления. Когда появляются средние и низкие находки, отправляйте сообщение в командный чат или создавайте задачу в трекере. Команда должна периодически просматривать эти находки, например, каждый спринт или перед каждым крупным релизом. Так находки не теряются, но и не блокируют повседневную работу.

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

Что на самом деле делает шлюз

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

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

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

Практический чек-лист

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

Итог

Ваш шлюз пайплайна не обязан ловить всё. Он должен ловить то, что важнее всего. Начните с критических и высоких как с жёстких блокировок. Пусть средние и низкие будут предупреждениями, которые команда просматривает по расписанию. Создайте простой процесс исключений для случаев, когда исправление невозможно сразу. Такая комбинация сохраняет пайплайн рабочим, а ваше продакшен-окружение — более безопасным, чем попытка блокировать всё подряд.