SAST, DAST, IAST, SCA: статический и динамический анализ кода

Безопасность приложений строится на нескольких типах автоматизированного анализа кода и работающих систем. SAST, DAST, IAST и SCA — четыре основных подхода, каждый из которых находит свой класс уязвимостей и работает на своём этапе разработки. Они дополняют друг друга, и зрелые программы application security используют все четыре одновременно, встраивая их в CI/CD-конвейер.

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

Зачем нужен автоматизированный анализ

Ручной аудит кода и пентесты остаются важной частью программы безопасности, но они дорогие, медленные и не масштабируются на ежедневные релизы. Современные команды выпускают код в продакшен десятки раз в день — проверять каждое изменение вручную невозможно. Автоматические сканеры закрывают типовые классы ошибок: SQL-инъекции, XSS, неправильное использование криптографии, утечки секретов, уязвимости зависимостей.

Цель автоматизации — не заменить ручной аудит, а отфильтровать массовые ошибки на ранних этапах. Чем раньше уязвимость найдена, тем дешевле её устранение. Исправление в IDE стоит минуты, в CI — часы, в продакшене — дни или недели работы команды плюс возможные репутационные потери.

SAST — статический анализ кода

Static Application Security Testing анализирует исходный код или байт-код без запуска приложения. Сканер строит модель кода — абстрактное синтаксическое дерево, граф потока управления, граф потоков данных — и применяет правила для поиска подозрительных паттернов. Источник пользовательского ввода (request parameter) → опасная функция (SQL-запрос) без санитизации = потенциальная SQL-инъекция.

Что находит SAST

• Инъекции: SQL, command, LDAP, XPath, NoSQL
• Cross-site scripting (XSS) — отражённый, хранимый, DOM-based
• Path traversal и file inclusion
• Хардкод секретов: API-ключи, пароли, токены в коде
• Небезопасную криптографию: устаревшие алгоритмы, ECB-режим, слабые ключи
• Race conditions и проблемы конкурентности (ограниченно)
• Insecure deserialization
• Buffer overflow в C/C++

Сильные стороны SAST

Главное преимущество — раннее обнаружение. SAST работает на этапе разработки, до сборки и развёртывания. Сканирование IDE-плагином в момент написания кода даёт обратную связь за секунды. Полное сканирование репозитория в CI занимает от минут до часов в зависимости от объёма кода. SAST покрывает все ветки исполнения, включая редко используемые, которые DAST может пропустить из-за нехватки трафика.

Слабые места SAST

Главная проблема — ложные срабатывания. Статический анализ работает с моделью кода, не зная реального контекста выполнения. Сканер видит, что параметр приходит из HTTP-запроса и попадает в SQL, и сигнализирует об инъекции — но может не учитывать валидацию, происходящую в middleware, или ORM, экранирующий ввод. Команды, не настраивающие правила под свой код, тонут в шуме false positives и со временем игнорируют отчёты сканера.

Вторая проблема — language coverage. SAST-сканер должен понимать конкретный язык и фреймворк. Поддержка популярных языков (Java, C#, JavaScript, Python, Go) развита хорошо, экзотические языки и DSL поддерживаются хуже или не поддерживаются вовсе.

DAST — динамический анализ

Dynamic Application Security Testing работает с запущенным приложением как чёрный ящик. Сканер обходит сайт, отправляет специально сформированные запросы и анализирует ответы на признаки уязвимостей. Если на запрос с одинарной кавычкой в параметре приходит SQL-ошибка в ответе — потенциальная SQL-инъекция найдена.

Что находит DAST

• SQL-инъекции через анализ ответов и тайминга
• XSS через инъекцию payload и проверку рефлексии
• Misconfiguration сервера: открытые порты, отладочные интерфейсы, дефолтные пароли
• Уязвимости аутентификации: brute force, session fixation, слабые токены
• Уязвимости авторизации: горизонтальные и вертикальные эскалации
• SSRF — server-side request forgery
• XXE — XML external entity
• Insecure HTTP-заголовки, отсутствие защитных директив

Сильные стороны DAST

DAST не требует доступа к исходному коду — может проверять приложения, написанные на любом языке, использующие любые фреймворки, развёрнутые в любой конфигурации. Это делает DAST подходящим для аудита legacy-систем, сторонних компонентов, чёрных ящиков. Найденные уязвимости имеют меньше false positives — если сканер реально выполнил инъекцию и получил подтверждение, проблема почти наверняка реальна.

Слабые места DAST

Главная слабость — coverage. DAST видит только то, что обнаружил при обходе сайта. Скрытые эндпойнты, страницы за сложной авторизацией, формы с многоступенчатой логикой могут остаться непроверенными. Сканирование занимает часы, а полный обход больших приложений — сутки и дольше. Также DAST не находит уязвимости в неактивных ветках кода — если функция не вызывается во время сканирования, её проблемы не видны.

IAST — интерактивный анализ

Interactive Application Security Testing объединяет подходы SAST и DAST. Агент IAST подключается к приложению во время выполнения и наблюдает за внутренней работой — потоками данных, вызовами функций, обращениями к БД и файловой системе. Когда снаружи приходит запрос (от автотестов, ручного тестировщика, DAST-сканера), IAST видит весь путь обработки и обнаруживает уязвимости с высокой точностью.

Преимущества IAST

• Точность близка к ручному аудиту: видны и payload снаружи, и реальная обработка внутри
• Низкий уровень ложных срабатываний — IAST подтверждает уязвимость по факту реального выполнения
• Низкая нагрузка на CI: работает в фоне во время функционального тестирования
• Покрытие зависит от тестов: чем лучше функциональные тесты, тем шире охват IAST

Ограничения IAST

IAST требует развёртывания агента, что ограничивает применимость. Не каждая среда позволяет ставить агенты на приложения — production-системы, защищённые контуры, нестандартные платформы. Также IAST ограничен языками с поддержкой агентов: Java, .NET, Node.js, Python, Ruby поддерживаются основными вендорами; экзотика — нет.

SCA — анализ зависимостей

Software Composition Analysis проверяет используемые сторонние библиотеки и компоненты на известные уязвимости. Современное приложение состоит на 70–90% из open source-кода: фреймворки, библиотеки, утилиты. Каждая зависимость может содержать уязвимости, отсутствие которых в собственном коде не имеет смысла, если уязвимая библиотека работает рядом.

Как работает SCA

Сканер строит SBOM — Software Bill of Materials, полный список зависимостей с версиями. Каждая зависимость сверяется с базами уязвимостей: NVD, GitHub Advisory Database, OSV, базами производителей. Если найдена CVE с уязвимой версией библиотеки — формируется отчёт с рекомендацией обновления.

Уровни SCA

• Direct dependencies: библиотеки, явно объявленные в package.json, pom.xml, requirements.txt
• Transitive dependencies: зависимости зависимостей, часто составляют 70–80% от общего списка
• License compliance: проверка лицензий зависимостей на совместимость и регуляторные требования
• Malicious packages: обнаружение специально вредоносных пакетов в реестре npm/PyPI

Современные тренды в SCA

Простое сравнение версии с CVE даёт много шума. Современные SCA-инструменты идут глубже: анализируют, реально ли уязвимая функция вызывается из кода приложения. Если в библиотеке есть CVE в модуле, который не используется, риск низкий. Эта функциональность называется reachability analysis и существенно снижает количество false positives.

Сравнение четырёх подходов

Что находит и что не находит каждый

Главное практическое следствие — ни один из инструментов не покрывает все классы уязвимостей. Программа application security строится как комбинация подходов.

Метрики качества инструментов

Оценка сканеров идёт по нескольким параметрам. False positive rate и false negative rate определяют практическую ценность отчётов. Слишком много ложных срабатываний — команда игнорирует выводы. Слишком много пропусков — программа не защищает от реальных атак.

• True Positive (TP) — реальная уязвимость, найденная сканером
• False Positive (FP) — сканер сообщил об уязвимости, которой нет
• True Negative (TN) — корректно пропущенный безопасный код
• False Negative (FN) — реальная уязвимость, не найденная сканером
• Precision = TP / (TP + FP) — доля реальных уязвимостей среди отчётов
• Recall = TP / (TP + FN) — доля найденных уязвимостей от всех существующих

Бенчмарки вроде OWASP Benchmark Project позволяют сравнивать инструменты на стандартных наборах уязвимых и безопасных паттернов. Реальная эффективность всё равно зависит от настройки под конкретный стек и тип кода.

Интеграция в CI/CD

Сканирование, не встроенное в процесс разработки, не работает. Эпизодические отчёты раз в квартал собирают многие сотни срабатываний, которые никто не разбирает. Современный DevSecOps подразумевает встраивание проверок на каждом этапе.

Pre-commit hooks

Быстрые проверки в момент коммита: поиск секретов в diff, базовые правила SAST. Не должны занимать больше нескольких секунд, иначе разработчики начнут обходить. Инструменты: pre-commit, gitleaks, trufflehog.

Pull request checks

Полноценный SAST и SCA на изменённых файлах, инкрементальное сканирование. Результаты комментируются в PR, блокируют merge при критических находках. Время выполнения 2–10 минут — приемлемо для PR-flow.

Build pipeline

Полное сканирование SAST и SCA при сборке main-ветки. Результаты собираются в централизованный security-dashboard. Артефакты сборки помечаются с SBOM для последующего отслеживания.

Test environment

DAST и IAST запускаются параллельно с функциональным тестированием. DAST требует развёрнутого приложения, IAST — агента на приложении и активного выполнения тестов.

Production monitoring

RASP (Runtime Application Self-Protection) и WAF работают на проде, блокируя атаки в реальном времени. SCA продолжает мониторить SBOM на новые CVE в используемых компонентах.

Shift-left и shift-right

Концепция shift-left означает перенос безопасности на ранние этапы разработки: вместо проверки на проде или в QA — проверка в IDE и при коммите. Чем раньше найдена ошибка, тем дешевле её устранить. Стоимость исправления уязвимости в продакшене может быть в 100 раз выше, чем в кодинге.

Shift-right — продолжение защиты в продакшене: RASP, WAF, мониторинг аномалий, threat intelligence. Левая часть не покрывает все классы атак, в первую очередь zero-day и атаки на бизнес-логику. Зрелая программа использует оба направления.

Инструменты по категориям

Стоимостная модель

Затраты на AppSec-инструменты для команды в 50 разработчиков и 100 приложений ориентировочно:

• SAST коммерческий: $30 000–150 000 в год за подписку
• DAST коммерческий: $20 000–80 000 в год
• IAST: $40 000–200 000 в год (премиум-категория)
• SCA коммерческий: $20 000–100 000 в год
• Open source стек: бесплатно по лицензиям, но требует выделенных инженеров (1–2 человека full-time)

Open source подход экономит на лицензиях, но требует инженеров для настройки правил, поддержания базы знаний, разбора срабатываний. Коммерческие решения дают готовые правила, поддержку, обновления баз CVE, но обходятся дороже на масштабе. Гибридный подход распространён: open source для базового покрытия, коммерческий — для критичных систем и compliance.

Подводные камни внедрения

Установка инструмента без процесса

Покупка SAST-лицензии без построения процесса обработки находок приводит к тысячам непрочитанных срабатываний. Сначала процесс — кто разбирает, кто исправляет, как приоритизировать — потом инструмент. Без владельцев результатов даже лучший сканер бесполезен.

Игнорирование false positives

Команды, не вкладывающие время в тюнинг правил, получают шум. Шум приводит к alert fatigue, alert fatigue — к игнорированию даже реальных находок. Базовая гигиена — после первого сканирования выделить день на разметку всех находок и подавление повторяющихся false positives на уровне правил.

Блокировка релиза на любую находку

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

Отсутствие обучения разработчиков

Сканеры находят проблемы, но не объясняют, как их избегать. Без обучения секурити-практикам разработчики повторяют те же ошибки в новом коде. Эффективная программа AppSec включает регулярные тренинги, secure coding guidelines, security champions в продуктовых командах.

Инструмент сканирования — это 20% программы AppSec. Остальные 80% — процессы, обучение, культура. Лучший сканер бесполезен без команды, которая разбирает результаты и исправляет находки.

RASP — runtime защита

Runtime Application Self-Protection — относительно новый класс инструментов, выходящий за рамки классических SAST/DAST. RASP-агент работает внутри приложения в проде и блокирует атаки в реальном времени, в момент попытки эксплуатации. В отличие от WAF, который работает на сетевом уровне, RASP видит контекст приложения и точнее различает легитимный и атакующий трафик.

RASP полезен против zero-day-атак и атак на компоненты с не выпущенными ещё патчами. Минусы — нагрузка на производительность, сложность развёртывания, риск ложных блокировок легитимного трафика. RASP не заменяет другие классы инструментов, но дополняет их в защите production-окружения.

DevSecOps и culture

Технические инструменты работают в контексте организационной модели. DevSecOps — это подход, при котором безопасность становится общей ответственностью команды разработки и эксплуатации, а не отдельной функцией, появляющейся за неделю до релиза.

Признаки зрелой DevSecOps-культуры:

1. Security в DoD (Definition of Done) каждой задачи
2. Security champions в каждой продуктовой команде
3. Threat modeling на этапе проектирования
4. Регулярные обучения secure coding
5. Прозрачные метрики безопасности на дашбордах команд
6. Постмортемы инцидентов с blameless-подходом
7. Bug bounty программа или другие каналы внешних исследователей

Часто задаваемые вопросы

Можно ли обойтись только одним типом сканера

Для серьёзных приложений — нет. SAST не находит misconfiguration сервера, DAST — уязвимости в неактивных ветках кода, SCA — уязвимости в собственном коде, IAST требует хорошего тестового покрытия. Полноценная программа использует все четыре, иногда добавляя secret scanning, container scanning, IaC scanning.

С чего начать построение AppSec в небольшой компании

С SCA и secret scanning. Это инструменты с наибольшим соотношением польза/сложность внедрения: высокая точность, минимальный шум, бесплатные open source-варианты, быстрая интеграция. Уязвимые зависимости и утечки секретов — самые частые причины инцидентов в малом и среднем бизнесе.

Open source или коммерческий стек выбрать

Зависит от команды и бюджета. Open source даёт гибкость, но требует выделенного инженера на настройку и поддержку. Коммерческие решения экономят время команды, но стоят денег и могут вводить vendor lock-in. Для команды до 20 разработчиков обычно достаточно open source. Для крупных компаний с compliance-требованиями коммерческие инструменты часто оказываются необходимыми.

Чем сканеры отличаются от пентеста

Сканеры — это автоматизированные инструменты, работающие по правилам и сигнатурам. Пентест — ручной аудит, выполняемый специалистами, ищущими уязвимости творчески, в том числе в бизнес-логике. Сканеры закрывают типовые ошибки, пентест — нестандартные. Эти подходы дополняют друг друга, а не заменяют.

Что делать с тысячами находок после первого сканирования

Не разбирать все. Отсортировать по критичности и взять только high и critical в работу. Medium и low пометить как технический долг с планом устранения. Параллельно настроить подавление повторяющихся false positives на уровне правил, чтобы следующие сканирования давали меньше шума.

Как мотивировать разработчиков исправлять находки сканеров

Сделать процесс удобным: интеграция в IDE и PR, понятные описания с примерами исправления, реалистичные SLA, отсутствие наказаний за обнаружение проблем. Жёсткое принуждение работает плохо — приводит к саботажу или формальным исправлениям. Образование и поддержка работают лучше принуждения.

Заключение

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

Эффективность сканеров определяется не их техническими характеристиками, а зрелостью процессов вокруг них. Покупка топового инструмента без построения процесса обработки находок не повышает безопасность, а только генерирует шум. Начинать стоит с базовых элементов — SCA, secret scanning, basic SAST — и постепенно расширять стек по мере роста зрелости команды. Параллельно с инструментами развивается культура DevSecOps: общая ответственность за безопасность, обучение разработчиков, threat modeling на этапе проектирования. Без культурной составляющей даже лучшие инструменты остаются дорогостоящей формальностью.