SAST и DAST: что это, SCA и проверки в CI/CD просто

Коротко. SAST и DAST — что это: два способа автоматически искать уязвимости в приложении. SAST (статический анализ) читает исходный код без запуска и находит опасные конструкции: инъекции, секреты в коде, небезопасную работу с данными. DAST (динамический анализ) атакует уже запущенное приложение снаружи, как злоумышленник, и находит то, что видно только в работе: ошибки конфигурации, проблемы входа и сессий, лишнее в ответах сервера. SCA (анализ состава) проверяет сторонние библиотеки на известные уязвимости и лицензии. В CI/CD — конвейере сборки и выкладки — SAST и SCA запускают на каждое изменение кода, а DAST — на тестовом окружении перед релизом. Эти проверки не заменяют пентест, но ловят типовые ошибки до того, как код попадёт к пользователям.

Для руководителей разработки, владельцев продуктов и ИТ-директоров, которые слышат «надо внедрить DevSecOps» и хотят понять, что за этим стоит.

SAST и DAST: что это и чем отличаются

SAST — проверка кода без запуска

SAST (Static Application Security Testing) — статический анализ безопасности, при котором инструмент разбирает исходный код и ищет в нём шаблоны уязвимостей, не запуская приложение. Он показывает файл и строку, поэтому разработчику сразу понятно, что исправлять. Слабые стороны — ложные срабатывания и слепота к тому, что зависит от окружения: настройкам сервера, реальным правам, логике сценариев.

DAST — атака на работающее приложение

DAST (Dynamic Application Security Testing) — динамический анализ, при котором инструмент обходит запущенное приложение и отправляет ему вредоносные запросы, наблюдая за ответами. Язык и фреймворк не важны: проверяется то, что реально доступно по сети. Слабые стороны — нужен развёрнутый стенд и тестовые учётные записи, прогон долгий, а найденную проблему ещё надо сопоставить с кодом. Для API динамическому анализу нужна спецификация методов, например в формате OpenAPI, иначе сканер просто не узнает о части точек входа.

SCA — проверка чужого кода внутри вашего

SCA (Software Composition Analysis) — анализ состава приложения: какие сторонние библиотеки и пакеты в него входят, какие у них версии, есть ли для этих версий опубликованные уязвимости (CVE) и совместимы ли лицензии с вашим использованием. Современное приложение в большой степени собирается из открытых компонентов, поэтому уязвимость в популярной библиотеке становится уязвимостью вашего продукта. Побочный результат SCA — SBOM, перечень компонентов в стандартных форматах CycloneDX или SPDX. Он полезен и после релиза: когда публикуют уязвимость в популярной библиотеке, по SBOM сразу видно, какие продукты и версии затронуты, без ручного поиска по репозиториям.

Что ещё входит в безопасную разработку

• Поиск секретов — паролей, токенов и ключей API, случайно попавших в репозиторий.
• Проверка контейнеров — уязвимые пакеты в базовых образах.
• Проверка инфраструктуры как кода (IaC) — открытые хранилища, лишние права, небезопасные настройки в конфигурациях.
• IAST — гибрид, который наблюдает за приложением изнутри во время тестов.

Сравнение: SAST, DAST и SCA в одной таблице

Вывод из таблицы: проверки не конкурируют, а закрывают разные слои — свой код, чужой код и поведение в работе.

Где проверки стоят в CI/CD: шесть точек

1. До коммита. Поиск секретов на машине разработчика — чтобы ключ не попал в историю репозитория, откуда его уже не удалить полностью.
2. Запрос на слияние. Быстрый SAST по изменённым файлам и SCA по новым зависимостям; результаты — комментариями прямо к изменению.
3. Сборка. Полный SCA, формирование SBOM, проверка контейнерного образа и конфигураций инфраструктуры.
4. Тестовое окружение. DAST по развёрнутой версии с тестовыми учётными записями разных ролей.
5. Ворота релиза. Правило: в эксплуатацию не уходит сборка с новыми критичными находками без согласованного исключения.
6. Эксплуатация. Постоянная сверка SBOM с новыми опубликованными уязвимостями и регулярный DAST по боевой версии в согласованное окно.

Полный SAST по всему коду и долгий DAST обычно выносят в ночной прогон, чтобы не задерживать разработчиков на каждом изменении.

Как внедрить и не утопить команду в предупреждениях

Главная причина, по которой проверки отключают через месяц, — сотни находок в первый день и красная сборка без понятного выхода. Что работает:

• Базовая линия. Текущие находки фиксируются и разбираются планово, а сборку блокируют только новые критичные.
• Настройка правил под стек. Ложные срабатывания помечаются с обоснованием, правила, не относящиеся к вашему коду, выключаются.
• Владелец и сроки. У проверок есть ответственный, у находок — сроки исправления по критичности. Это часть общего процесса, описанного в статье об управлении уязвимостями.
• Находки — в трекер задач. Не отдельный отчёт, который никто не открывает, а задачи в том же месте, где работает команда.
• Обучение на своих находках. Разбор реальных ошибок команды полезнее абстрактного курса.
• Метрики. Число новых критичных находок, время исправления, доля исключений.

Как ориентир зрелости процесса используют OWASP SAMM, как перечень практик безопасной разработки — NIST SP 800-218 (Secure Software Development Framework), как набор требований к самому приложению — OWASP ASVS.

Почему SAST, DAST и SCA не заменяют пентест

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

Рабочая связка: автоматические проверки в CI/CD на каждое изменение и ручной пентест перед крупными релизами и периодически.

Чек-лист запуска безопасной разработки

• Определены продукты и репозитории, с которых начинаем
• Поиск секретов подключён до коммита и в конвейере
• SCA запускается на каждую сборку, формируется SBOM
• SAST работает на запросах на слияние с базовой линией
• Для DAST есть стабильное тестовое окружение и учётные записи ролей
• Сформулированы правила ворот релиза и порядок исключений
• Назначен владелец проверок и сроки исправления по критичности
• Находки попадают в трекер задач команды
• Ложные срабатывания помечаются с обоснованием
• Метрики процесса пересматриваются регулярно
• Ручной пентест запланирован для крупных релизов

Сколько стоит запуск безопасной разработки

У Viviar это пакет «Запуск безопасной разработки»: аудит одного продукта, разбор кода и список того, что чинить, — от 20 300 BYN; с внедрением проверок SAST, DAST и SCA в сборку — от 43 600 BYN. Работу ведёт команда AppSec направления кибербезопасности, а в проектах разработки те же проверки встроены в процесс с первого релиза.

Частые вопросы

SAST и DAST — что это простыми словами?

SAST читает исходный код без запуска и ищет в нём опасные конструкции, указывая файл и строку. DAST атакует работающее приложение снаружи и смотрит на реакцию, не заглядывая в код. Первый находит ошибки раньше и точнее показывает место, второй видит проблемы конфигурации и поведения, которых в коде не видно.

Что внедрять первым: SAST, DAST или SCA?

Обычно начинают с поиска секретов и SCA: они быстро подключаются, дают мало ложных срабатываний и закрывают известные уязвимости в библиотеках. Затем SAST на запросах на слияние с базовой линией, чтобы блокировать только новые проблемы. DAST добавляют, когда есть стабильное тестовое окружение с учётными записями разных ролей.

Замедлят ли проверки безопасности сборку?

Если всё запускать на каждое изменение — да. Поэтому на запросе на слияние работают быстрые проверки только изменённого кода и новых зависимостей, а полный SAST и DAST выносят в ночной прогон или на тестовое окружение перед релизом. Так разработчик получает обратную связь сразу, а тяжёлые проверки не стоят у него на пути.

Можно ли заменить пентест автоматическими проверками?

Нет. SAST, DAST и SCA находят известные классы ошибок, но не понимают бизнес-логику: доступ к чужим данным через подмену номера, повторное применение скидки, цепочки из нескольких мелких уязвимостей. Это находит человек при пентесте. Разумная связка — автоматические проверки на каждое изменение и ручной пентест перед крупными релизами.

Сколько стоит внедрить SAST, DAST и SCA?

У Viviar пакет «Запуск безопасной разработки» стоит от 20 300 BYN: аудит одного продукта, разбор кода и список того, что чинить. С внедрением проверок SAST, DAST и SCA в сборку — от 43 600 BYN. Точная цена зависит от числа продуктов, языков и устройства конвейера.

Вывод

Если коротко отвечать на вопрос «SAST и DAST — что это», то это автоматические проверки своего кода и работающего приложения, а SCA добавляет к ним контроль чужих библиотек. Встроенные в CI/CD с базовой линией, владельцем и сроками, они ловят типовые уязвимости на каждом изменении, а пентест остаётся для логики и сложных цепочек. Если хотите встроить проверки в свою сборку, расскажите о продукте и конвейере: за полчаса разговора наметим, с каких проверок начать.

Источники: OWASP Software Assurance Maturity Model (SAMM), OWASP Application Security Verification Standard (ASVS), OWASP DevSecOps Guideline, OWASP Top 10 (owasp.org); NIST SP 800-218 Secure Software Development Framework (csrc.nist.gov); CycloneDX (cyclonedx.org); SPDX (spdx.dev); CVE (cve.org); Common Vulnerability Scoring System (first.org).