Коллеги, приветствую 👋🏻
На прошлой неделе здесь была задача про DevSecOps‑подход и падающие чекеры. Обсудим ее.

Варианты ответов были следующие:
❌Отключать все security-чекеры.
Неверно, этот вариант ломает саму идею и риски бизнеса растут.

❌Блокировать релизы при падении пайплайна.
Выглядит проще всего, но можно блокировать разработку и вообще потерять доверие.

❌Скрывать отчеты.
Не подойдет, потому что безопасноть должна быть видна разработчикам.

✅Отправлять все срабатывания в бэклог и брать в работу только critical.
Это правильный ответ. Но есть ряд важных уточнений и дополнительных шагов, которые многим из вас могут показаться очевидными (и это круто).

⏩Как выглядит корректный DevSecOps-подход
1. Ввести базовый baseline и не блокировать по старым проблемам
• Фиксируем текущее состояние: все существующие SAST/SCA-находки объявляем baseline
• Пайплайн не должен падать из-за уже известных старых уязвимостей
• Новые проблемы, появившиеся в конкретном PR или коммите, — вот их уже можно блокировать или жёстко контролировать

2. Приоритизировать по критичности и риску
Всё найденное уходит в бэклог, но работа ведётся по severity:
• Critical / High — обязательны к исправлению в разумные сроки (SLA)
• Medium / Low — либо откладываются, либо помечаются как неактуальные / ложные срабатывания

3. Уменьшать шум и ложные срабатывания
• Правила и сигнатуры SAST/SCA должны быть настроены так, чтобы реже цеплять несущественные находки
• Часть правил имеет смысл перевести в режим информирования, а не фейла

4. Ужесточать политики постепенно
• Сначала пайплайн падает только по критическим уязвимостям
• Потом добавляются high
• И только после расчистки старой базы — важные средние

DevSecOps — это не про «сломать разработку ради безопасности», а про управляемые риски и эволюцию процессов, которые команды реально готовы поддерживать 📌