SAST, DAST и IAST: автоматизация проверок безопасности в CI/CD

Разница в одной таблице

SAST (static application security testing) анализирует исходный код, не запуская его. DAST (динамическое тестирование) отправляет реальные запросы в работающее приложение, как это сделал бы атакующий. IAST (интерактивное тестирование) встраивает агент в запущенное приложение и следит за движением данных, пока его прогоняют тесты или QA.

Ни один подход не заменяет другие: каждый видит свою часть рисков.

Что каждый находит и пропускает

SAST хорошо находит:

• инъекции, когда ввод доходит до опасных вызовов (SQL, shell, пути к файлам);
• захардкоженные секреты и слабую криптографию;
• небезопасные настройки фреймворка, видимые в коде.

SAST пропускает конфигурацию сервера и TLS, проблемы, проявляющиеся только во время работы, и большинство ошибок бизнес-логики. Он также даёт ложные срабатывания: не всегда понятно, проверили ли ввод где-то в другом месте.

DAST хорошо находит:

• отсутствующие заголовки безопасности, флаги cookie, открытые отладочные страницы;
• отражённый XSS и часть инъекций, которые можно вызвать снаружи;
• ошибки конфигурации реального сервера, прокси и TLS.

DAST пропускает участки, до которых не может добраться (страницы за сложным входом, многошаговые сценарии), и не говорит, какую строку исправлять.

IAST объединяет оба взгляда и даёт меньше ложных срабатываний, но видит только код, который выполняют ваши тесты, а агент должен поддерживать вашу среду выполнения. Зрелых open-source вариантов мало, поэтому большинство команд начинают с SAST и DAST.

С каких инструментов начать

• Semgrep — быстрый SAST с читаемыми правилами и наборами правил сообщества для многих языков. Собственные правила выглядят как код, который они ищут.
• CodeQL — глубокий семантический анализ, доступен в GitHub code scanning.
• OWASP ZAP — самый распространённый open-source DAST. Baseline scan пассивный и безопасен для общих сред; full scan активно атакует, и ему место на изолированном staging.
• Сканеры зависимостей и секретов (Dependabot, Gitleaks и подобные) закрывают то, что правила SAST обычно не покрывают.

Минимальная настройка в GitHub Actions

SAST на каждый pull request, DAST против staging по расписанию:

name: security
on:
  pull_request:
  schedule:
    - cron: "0 2 * * *"

jobs:
  semgrep:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    container: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
      - run: semgrep scan --config p/default --error

  zap-baseline:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          docker run --rm -v "$PWD:/zap/wrk" ghcr.io/zaproxy/zaproxy:stable \
            zap-baseline.py -t https://staging.example.com -c zap-rules.conf

Флаг --error заставляет Semgrep завершать задачу с ошибкой при находках. Файл zap-rules.conf говорит ZAP, какие правила должны давать FAIL, WARN или игнорироваться, — так вы сами решаете, что ломает сборку. Версии actions и образов фиксируйте по своей политике обновлений.

Как не утонуть в ложных срабатываниях

1. Начните в режиме «только отчёт». Соберите результаты, разберите их, затем включайте блокировку.
2. Блокируйте только надёжные правила высокой критичности. Всё остальное — в дашборд или еженедельный разбор.
3. В pull request сканируйте только diff. Разработчики исправляют то, что только что написали; старые находки идут в отдельный бэклог. Semgrep поддерживает diff-aware сканирование относительно базового коммита.
4. Подавляйте с объяснением. Используйте inline-игнор (nosemgrep) или конфиг правил с комментарием «почему», чтобы следующий человек понял решение.
5. Пишите свои правила под свои шаблоны — например, «никогда не вызывать наш raw SQL helper с конкатенацией строк». Шума от них почти нет.
6. Назначьте ответственного. Кто-то должен смотреть результаты новых правил и настраивать конфиг, иначе инструмент начнут игнорировать.
7. Дайте DAST авторизацию. Тестовый аккаунт позволит ZAP дойти до реального приложения, а не только до страницы входа.

Частые ошибки

• Запуск активного DAST против продакшна или общей базы данных.
• Включение всех правил в первый же день и падение каждой сборки.
• Восприятие чистого отчёта как доказательства безопасности. Инструменты не понимают вашу бизнес-логику — code review и моделирование угроз по-прежнему нужны.
• Отчёты нигде не хранятся. Сохраняйте артефакты, чтобы сравнивать динамику между релизами.