"Сдвиг влево" (shift left) означает перенос проверок безопасности с предрелизного шлюза к самой ранней точке, где дефект дёшево исправить — в редактор разработчика и в pull request. Экономика хорошо задокументирована: исследования NIST и IBM стабильно показывают, что баг, пойманный на этапе проектирования или написания кода, стоит долю от стоимости бага, найденного в проде. Но сдвиг влево — это не покупка новых сканеров. Это размещение нужного контроля на нужном этапе, его настройка так, чтобы инженеры ему доверяли, и честное признание того, чего автоматизация найти не может.
Начните до кода: моделирование угроз
Самая дешёвая для исправления уязвимость — та, которую вы исключаете на этапе проектирования. Моделирование угроз относится к стадии дизайна функции, а не к моменту после неё. Тяжёлый процесс не нужен — 30-минутной сессии по четырём вопросам из Threat Modeling Manifesto достаточно для большинства задач: Что мы строим? Что может пойти не так? Что мы с этим сделаем? Хорошо ли мы справились?
Используйте STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) как подсказку для каждого потока данных, пересекающего границу доверия. Новый эндпоинт, принимающий URL от пользователя, немедленно поднимает флаг Server-Side Request Forgery (OWASP A10:2021, CWE-918); новая загрузка файлов — path traversal (CWE-22) и неограниченную загрузку (CWE-434). Зафиксируйте выводы как критерии приёмки по безопасности в тикете, чтобы они были проверяемыми, а не декларативными.
Пайплайн: четыре автоматических слоя
Прагматичный пайплайн запускает всё более тяжёлые проверки по мере продвижения кода к проду. Быстрые проверки блокируют каждый коммит; медленные и "шумные" работают вне основного пути.
- Pre-commit / IDE: сканирование секретов (gitleaks, trufflehog) и линтеры. Перехват утёкшего секрета до его попадания в удалённый репозиторий экономит инцидент с ротацией ключей. Этот слой должен быть почти мгновенным.
- SAST на pull request: Static Application Security Testing анализирует исходный код без его запуска — эффективно против инъекций, зашитых секретов и небезопасных API. Инструменты вроде Semgrep, CodeQL или SonarQube работают за минуты. Ключевое правило: блокируйте только по правилам с высокой достоверностью. SAST-шлюз, заливающий PR ложными срабатываниями, будет проигнорирован или отключён в течение одного спринта.
- SCA / сканирование зависимостей: Software Composition Analysis — пожалуй, контроль с наивысшим ROI, потому что большая часть современного кода стороння. Запускайте
npm audit, OWASP Dependency-Check, Trivy или Snyk по сгенерированному SBOM (CycloneDX или SPDX). Сверяйтесь с каталогом CISA KEV и приоритизируйте по показателю EPSS, а не по сырому CVSS — CVSS 9.8 без известного эксплойта часто менее срочен, чем 7.5, активно используемый в атаках. - DAST на staging: Dynamic Application Security Testing проверяет работающее приложение извне. OWASP ZAP или Nuclei могут запускать пассивный базовый скан при каждом деплое и полный активный скан ночью. DAST находит проблемы времени выполнения, невидимые для SAST — неверно настроенные заголовки, дефекты аутентификации, отражённый XSS в отрендеренном ответе.
Сделайте шлюзы заслуживающими доверия
Главный сценарий провала сдвига влево — усталость от алертов. Если сканер выдаст 400 находок на первом запуске и заблокирует сборку, разработчики обойдут его. Защищайте соотношение сигнал/шум осознанно:
- Блокируйте сборку только на новых находках высокой критичности и высокой достоверности, внесённых текущим изменением — используйте базовую линию/дифф, чтобы старый долг не блокировал сегодняшний PR.
- Оформляйте подавления как код. У каждой проигнорированной находки есть документированная причина и владелец в файле под контролем версий, а не клик в дашборде.
- Отслеживайте SLA по устранению уязвимостей по критичности. Например: критичные — за 7 дней, высокие — за 30, средние — за 90. Измеряйте среднее время устранения, а не только число открытых задач.
- Сводите всё в одно место. Агрегация вывода SAST/DAST/SCA (например, через DefectDojo или формат SARIF в вашем код-хосте) дедуплицирует находки и даёт единую картину риска.
Где ручной пентест по-прежнему незаменим
Автоматизация — это пол, а не потолок. Сканеры сопоставляют шаблоны; они структурно слепы к дефектам, требующим понимания замысла. Ни один SAST- или DAST-инструмент надёжно не найдёт:
- Дефекты бизнес-логики — покупка товара в отрицательном количестве, пропуск шага оплаты, состояния гонки в оформлении заказа. Это требует человека, понимающего, что приложение должно делать.
- Нарушение контроля доступа и IDOR (OWASP A01:2021, CWE-639) — сканер не знает, что пользователь A не должен читать счёт пользователя B. Авторизация — это контекст, а контексту нужен тестировщик.
- Цепочки эксплойтов — незначительная утечка информации плюс слишком либеральная политика CORS плюс слабый контроль сессии могут сложиться в полный захват аккаунта. Инструменты оценивают находки изолированно; атакующие их связывают.
Полезная периодичность: непрерывное автоматическое тестирование при каждом изменении, точечный ручной пентест при каждом крупном релизе или существенном изменении архитектуры и ежегодное полномасштабное вовлечение — в соответствии с методологиями OWASP WSTG и PTES. Если вы попадаете под PCI DSS, ежегодные пентесты и пентесты после существенных изменений — жёсткое требование, а не опция.
Порядок внедрения
Не переключайте все шлюзы в режим "блокировки" в первый же день. Запустите новые инструменты в режиме только-отчёт на один-два спринта, приглушите шум, согласуйте SLA с инженерами и только затем включайте принуждение. Начните со сканирования секретов и SCA — у них лучший сигнал и самые понятные исправления — затем добавьте SAST, а в конце DAST. Сдвиг влево удаётся, когда безопасность становится фоновым свойством пайплайна, которое разработчики почти не замечают, и проваливается в момент, когда превращается в налог, который их раздражает.