Каждая команда, в которую я приходил, повторяет одну и ту же мантру — будто это закон физики: либо безопасность, либо скорость, выбирай что-то одно. Либо медленные релизы, либо риск. Я не согласился ни на то, ни на другое. Дальше — история о том, как я собрал security gates в CI/CD pipeline, которые работают параллельно со сборкой: безопасность стала невидимой, а деплой не потерял ни минуты.
Схема, которая сломана с самого начала
Опишу «нормальный» процесс безопасности — скорее всего, вы через это проходили.
Security review случается один раз, где-то прямо перед релизом. В прод уезжают container images, которые вообще никто ни разу не сканировал. RBAC-политики скопированы из ответа на Stack Overflow трёхлетней давности. А все просто тихо надеются, что пронесёт.
Потом кто-то наконец вешает сканер на pipeline — и делает это худшим из возможных способов. Скан запускается после сборки. Разработчик ждёт результат 45 минут. Один medium-финдинг блокирует весь pipeline. Через неделю команда уже обходит процесс стороной, и «решение» всегда одно: отключить gate.
Об этом не говорят на конференциях. Безопасность, которая тормозит, — это безопасность, которую выключают. Ты не становишься защищённее. Ты получаешь галочку и ложное чувство спокойствия.
Идея, которая меняет всё: гонять параллельно
Секрет — не в модном фреймворке и не в вендорской платформе. Секрет в параллельном выполнении.
Сканы не запускаются после сборки. Они идут рядом с ней. Pipeline делает свою обычную работу — компиляция, тесты, упаковка, — а security-стадии крутятся в том же окне, по тем же часам. Дополнительное время для разработчика — практически ноль.
Что реально работает:
- SonarQube на каждый pull request. Качество кода и поиск уязвимостей прилетают комментариями в ревью ещё до того, как PR откроет живой человек.
- Trivy сканирует каждый container image на этапе сборки — не после деплоя, когда уже поздно.
- Terraform-планы проверяются против security-политик до того, как коснутся инфраструктуры. Тот самый публичный S3-бакет ловится ещё до того, как появится.
- Проверки зависимостей идут в ту же минуту, что и unit-тесты.
- Jenkins дирижирует всем потоком: прошли все gate — авто-апрув и деплой; что-то упало — разработчик получает фидбек прямо в своём pull request, а не письмом через три недели.
Блокирует только critical. Всё остальное — в расписание.
Вот решение, благодаря которому всё это выжило при встрече с живыми разработчиками.
Деплой останавливает только critical. Всё остальное — medium, low, информационное — трекается, заводится в тикеты и планируется. Один шумный финдинг больше не берёт релиз в заложники. Gate строгий там, где обязан, и молчит везде, где можно, — поэтому ему доверяют, а не воюют с ним.
Безопасность перестаёт быть глухой стеной и становится тем, чем должна была быть с самого начала: комментариями в ревью, там, где разработчик и так работает.
Результаты
- Ноль critical-уязвимостей в проде — пойманы на этапе PR, а не в post-mortem.
- Скорость деплоя не изменилась. Даже чуть выросла — потому что никто больше не ждёт последовательный скан.
- Покрытие ушло от «квартального аудита, которого все боятся» к «каждый коммит, автоматически».
И мой любимый итог, которого я не планировал: разработчики перестали отключать security-проверки. Не потому что я заставил, — потому что они забыли, что проверки вообще есть. Это высшая похвала для security pipeline.
Настоящий вывод
Тот самый shift left, который все упоминают на слайдах, — это не продукт, который покупают. Это решение в дизайне. Перенеси фидбек в момент, когда пишется код; сделай его параллельным, чтобы он ничего не стоил; и блокируй только то, что реально нельзя пускать в прод.
Безопасность, которая тормозит, — это безопасность, которую отключат. Сделай её невидимой — или потеряешь совсем.
Безопасность — не блокер. Это фича твоего pipeline.
И вопрос напоследок: твой security gate работает параллельно — или это то самое бутылочное горлышко, которое тихо ненавидит вся команда?