Shift-Left Security

Уязвимость за $100 и уязвимость за $10 000

IBM Systems Sciences Institute опубликовал данные, которые с тех пор повторяют в каждой презентации про безопасность: исправление бага, найденного на этапе проектирования, стоит условные $100, на этапе тестирования — $1 500, а в продакшене — до $10 000. Конкретные множители варьируются от исследования к исследованию (кто-то говорит 6x на этапе имплементации, кто-то 30x на этапе QA, кто-то 100x в продакшене), но тренд один и тот же — экспоненциальный рост стоимости. Для уязвимостей безопасности всё ещё хуже, потому что к стоимости исправления добавляется стоимость инцидента: утечка данных, расследование, уведомление пользователей, штрафы регуляторов. IBM Cost of a Data Breach Report 2025 оценивает среднюю стоимость утечки данных в $4.88 миллиона.

Shift-left security — идея о том, что проверки безопасности нужно сдвигать влево по временной шкале разработки, ближе к моменту написания кода. Вместо того чтобы отдавать готовое приложение на penetration testing за неделю до релиза (и получать отчёт на 40 страниц с критическими находками, когда менять архитектуру уже поздно), вы встраиваете автоматические проверки в каждый pull request, обучаете разработчиков распознавать типичные паттерны уязвимостей и проектируете инфраструктуру так, чтобы безопасные решения были путём наименьшего сопротивления.

Почему security review перед релизом сломан

Классическая модель выглядит так: команда безопасности проводит ручной аудит перед каждым крупным релизом. У этой модели три фундаментальных проблемы.

Первая — масштаб. Netflix в своём блоге «Scaling Appsec at Netflix» описывает ситуацию, с которой сталкиваются все растущие компании: количество микросервисов и приложений растёт быстрее, чем команда безопасности. Когда у вас 500 сервисов и 5 security-инженеров, per-app security assessment физически невозможен. Astha Singhal из Netflix формулирует это прямо: модель ручного аудита каждого приложения не масштабируется.

Вторая проблема — время. Если вы деплоите 10 раз в день (а элитные команды по DORA деплоят чаще — подробнее в главе про CI/CD), то security review не может быть гейтом перед каждым деплоем. Он либо становится узким местом и убивает delivery velocity, либо его начинают обходить «для срочных фиксов» — и он перестаёт работать.

Третья — контекст. Когда security-инженер смотрит на код, написанный три месяца назад командой, с которой он раньше не работал, он тратит часы на понимание бизнес-логики, прежде чем может оценить риски. Разработчик, который этот код писал, мог бы сам увидеть проблему за минуты — если бы знал, на что смотреть.

Paved Roads: подход Netflix

Netflix предложил альтернативу, которую они называют Security Paved Road. Идея в том, что вместо проверки каждого приложения на безопасность вы строите инфраструктуру, которая делает безопасный путь — самым простым. Для типичного приложения на paved road инженер Netflix может пройти путь от git init до production-ready, полностью аутентифицированного, доступного из интернета приложения примерно за 10 минут. И это приложение уже использует правильные паттерны аутентификации, авторизации, хранения секретов и TLS-сертификатов.

Ключевой сдвиг в мышлении: вместо вопроса «расскажите, как ваше приложение делает эту важную штуку с безопасностью?» команда безопасности задаёт бинарный вопрос — «вы используете paved road продукт, который это делает?». Это превращает security review из экспертного анализа в чеклист.

Security Champions: масштабирование через людей

Технические решения работают для типичных кейсов, но нетипичные кейсы всегда будут. Security Champions — программа, в которой один разработчик из каждой продуктовой команды берёт на себя роль контактного лица по безопасности. Этот человек проходит дополнительное обучение, участвует в регулярных встречах с командой безопасности, и становится первой линией для вопросов о безопасности внутри своей команды.

Программа работает по нескольким причинам. Security champion уже имеет контекст кода и бизнес-логики своей команды — ему не нужно тратить часы на погружение. Он сидит рядом с коллегами (или в том же Slack-канале) и может поймать проблему на этапе обсуждения дизайна, задолго до написания кода. Он снимает нагрузку с центральной команды безопасности, позволяя ей сфокусироваться на архитектурных решениях и инструментах, а повседневные вопросы вроде «как правильно валидировать этот input» решать на уровне продуктовой команды.

Mend.io в своём обзоре программ security champions приводит данные: команды с активными security champions выпускают код с меньшим количеством уязвимостей и быстрее реагируют на findings от автоматических сканеров, потому что у них есть человек, который понимает и контекст проблемы, и контекст кода.

Что значит shift-left на практике

Shift-left — это набор конкретных практик, которые складываются в систему.

На уровне IDE: линтеры и расширения (Semgrep в VS Code, SonarLint) подсвечивают типичные уязвимости прямо в редакторе, пока вы пишете код. Это самая левая точка, куда можно сдвинуть проверку.

На уровне CI: SAST и DAST сканеры проверяют каждый pull request и блокируют мерж при обнаружении критических проблем. Важно настроить их так, чтобы они сканировали только изменённые файлы (инкрементальное сканирование), иначе 20-минутное полное сканирование убьёт ту самую скорость обратной связи, которую мы пытаемся сохранить.

На уровне архитектуры: paved roads, secure-by-default фреймворки, централизованные библиотеки для аутентификации и авторизации. Вы не можете написать SQL-инъекцию, если ORM не даёт вам формировать raw queries. Вы не можете забыть проверить аутентификацию, если API gateway делает это за вас.

На уровне людей: security champions, обучение (не формальные курсы по compliance, а практические воркшопы про конкретные уязвимости в вашем стеке), и культура, в которой находить уязвимость в своём коде — это хорошо, а не стыдно.

Trade-offs и рекомендации

Shift-left требует инвестиций: инструменты, обучение, время security-инженеров на создание paved roads. И shift-left не отменяет penetration testing — он сокращает количество находок, которые pentester обнаружит, с десятков до единиц, но те единицы будут сложными архитектурными проблемами, которые автоматика не поймает.

Начните с трёх шагов. Первый: добавьте SAST-сканер в CI на ваши самые критичные репозитории (те, что обрабатывают пользовательские данные или платежи). Второй: найдите одного заинтересованного разработчика в каждой из двух-трёх ключевых команд и предложите им роль security champion — дайте им время на обучение и доступ к security-команде. Третий: посмотрите на самые частые security-находки за последний год и спросите себя: можно ли решить эту проблему на уровне инфраструктуры, чтобы разработчик физически не мог допустить эту ошибку? Если да — это ваш первый paved road проект.