Налаштування DAST для сайту: динамічний аналіз безпеки

Проблема: вразливості, які не бачить SAST

Ви використовуєте статичний аналіз коду, але production все одно зламують через неправильну конфігурацію Nginx або IDOR в API, який не покритий тестами. SAST аналізує код, а працює застосунок в оточенні — з сервером, middleware, сторонніми сервісами. Саме тут виникають runtime-вразливості. DAST (Dynamic Application Security Testing) вирішує цю проблему: він атакує застосунок як зовнішній зловмисник і знаходить те, що приховано від статики.

Ми налаштовуємо DAST для сайтів і API вже 10+ років. За цей час провели понад 50 проєктів з безпеки, від інтернет-магазинів до фінтех-платформ. Один з кейсів: клієнт втратив $18k–26k через SQL-ін'єкцію, яку не бачив SAST. Після впровадження ZAP у CI/CD такі вразливості перестали потрапляти в production. У середньому економія на ручному аудиті сягає 70% — автоматизація окупається за пару місяців. За даними OWASP Top 10, близько 40% критичних вразливостей належать до runtime-категорії, а середня вартість витоку даних для малого та середнього бізнесу — $27k–39k.

Чому DAST не замінити SAST?

DAST перевіряє працюючий застосунок у реальному оточенні. Він бачить:

• Неправильну конфігурацію сервера (відкриті CORS, слабкі заголовки)
• Runtime-вразливості (RCE, SSRF, IDOR)
• Проблеми з автентифікацією (невалідні сесії, слабкі токени)

SAST аналізує код, але не знає, як він виконується. DAST же діє з точки зору хакера. Наприклад, X-Frame-Options налаштовується на сервері, і SAST його не перевірить. DAST надішле запит і побачить, що заголовок відсутній. Без DAST ви ризикуєте пропустити до 95% runtime-вразливостей, які становлять 40% усіх критичних проблем.

Як інтегрувати DAST у CI/CD?

Ми інтегруємо DAST у пайплайн, щоб автоматично знаходити вразливості до деплою. Ось типовий процес:

1. Вибір інструменту: для веб-сайтів — OWASP ZAP (open source, гнучкий), для API — ZAP API scan або Nuclei.
2. Налаштування правил: визначаємо, які вразливості критичні (SQLi, XSS), а які — попередження.
3. Інтеграція з CI/CD: запуск при кожному пуші або за розкладом, генерація звіту, фейл пайплайну при критичних знахідках.
4. Кастомізація: додаємо authentication, налаштовуємо scope, виключаємо чутливі ендпоінти.

Приклад OWASP ZAP у GitHub Actions

# .github/workflows/dast.yml name: DAST on: push: branches: [main] schedule: - cron: '0 2 * * 1' jobs: zap-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Start application run: | docker compose -f docker-compose.test.yml up -d sleep 30 - name: Run ZAP Baseline Scan uses: zaproxy/[email protected] with: target: http://localhost:3000 rules_file_name: .zap/rules.tsv cmd_options: '-a' - name: Upload ZAP report uses: actions/upload-artifact@v4 if: always() with: name: zap-report path: report_html.html - name: Stop application if: always() run: docker compose -f docker-compose.test.yml down 

# .zap/rules.tsv # rule_id action reason 10017 WARN # X-Frame-Options header 10038 WARN # Content Security Policy 40012 FAIL # Cross Site Scripting 40018 FAIL # SQL Injection 90011 IGNORE # Charset mismatch 

Порівняння інструментів DAST

ZAP краще підходить для автоматизації в CI/CD: швидкий baseline scan (5-10 хв) і детальний full scan. Nuclei ефективний для перевірки конкретних CVE — ви запускаєте його за 5 хвилин і отримуєте список відомих вразливостей. Burp Suite використовується для ручного пентесту, коли потрібно глибоко протестувати бізнес-логіку.

Таблиця етапів налаштування DAST

Що входить у налаштування DAST

У рамках послуги ми:

• Аналізуємо архітектуру застосунку та обираємо інструменти.
• Налаштовуємо OWASP ZAP (або Nuclei) у вашому CI/CD (GitHub Actions, GitLab CI, Jenkins).
• Пишемо кастомні правила для фільтрації хибних спрацьовувань.
• Налаштовуємо автоматичний регрес: якщо в новій версії з'явилася критична вразливість — пайплайн падає.
• Підключаємо сканування за розкладом (щотижнево).
• Навчаємо команду роботі зі звітами та інтерпретації результатів.
• Надаємо документацію: конфігурації, правила, інструкцію з додавання нового проєкту.
• Супроводжуємо 2 тижні після впровадження: коригуємо правила, додаємо винятки.

Типові помилки при впровадженні DAST

1. Сканування production-оточення. Активне сканування може зламати дані. Завжди використовуйте staging.
2. Ігнорування автентифікації. DAST повинен ходити як авторизований користувач, інакше він не побачить захищені ендпоінти.
3. Відсутність фільтрації хибних спрацьовувань. Без кастомних правил ZAP видає сотні попереджень, які ніхто не дивиться.
4. Запуск лише ручного сканування. Автоматизація в CI/CD — єдиний спосіб не пропускати вразливості.

Терміни та вартість

Терміни залежать від складності:

• Базове налаштування ZAP у CI/CD: 1-2 дні.
• • Nuclei та Burp Suite: 3-5 днів.

  Вартість розраховується індивідуально. Ви отримуєте стабільний DAST-пайплайн, який захищає від критичних вразливостей. Отримайте консультацію — ми обговоримо ваш проєкт і підберемо оптимальне рішення. Ми гарантуємо, що налаштування не зламає staging, і надаємо підтримку після впровадження.

  Приклад конфігурації правил для ZAP

  # rule_id action reason 90001 IGNORE # Application error disclosure 90011 IGNORE # Charset mismatch 10017 WARN # X-Frame-Options header 10038 WARN # Content Security Policy 40012 FAIL # Cross Site Scripting 40018 FAIL # SQL Injection 

  Зв'яжіться з нами, щоб почати налаштування DAST вже сьогодні. Замовте консультацію — ми допоможемо захистити ваш проєкт від runtime-вразливостей.