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 уже знает код и бизнес-логику команды — погружаться часами не нужно. Он сидит рядом с коллегами (или в том же канале корпоративного чата) и ловит проблемы на этапе обсуждения дизайна, до того как код вообще написан. Он снимает нагрузку с центральной security-команды: та фокусируется на архитектурных решениях и инструментах, а вопросы уровня «как правильно валидировать этот input» закрываются внутри продуктовой команды.

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

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

Shift-left складывается из набора практик на разных уровнях.

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

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

На уровне архитектуры — 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 проект.