How do you integrate DAST scanning into a CI/CD pipeline while keeping false positives manageable?

Passive vs active DAST: passive (baseline) scanning observes traffic and checks responses for obvious issues (missing headers, cookies without flags, obvious information disclosure) without sending attack payloads. It's fast and produces low false-positive rates. Active scanning sends attack payloads to every parameter — comprehensive but slow (hours for a complex app) and generates significant noise.

Pipeline placement:

• PR gate: passive DAST only. OWASP ZAP's -t baseline mode runs in seconds and is suitable for PR gates for the most critical pages.
• Nightly / pre-release: full active DAST scan against a staging environment with seeded test data. Run against a dedicated test user account that has permission to all features — active scanning without auth misses most app-specific vulnerabilities.

False positive management:

1. Keep a zap-suppressions.json or equivalent ignore list in source control.
2. For each false positive, add an entry with: the rule ID, the URL pattern, the reason it's a false positive, and the date added plus ticket reference.
3. Review suppressions quarterly — false positives from an old tech stack may become valid findings after a framework upgrade.

Auto-triage: configure the pipeline to auto-file findings at Critical and High severity in JIRA, with a label that identifies them as DAST findings. Medium and Low findings go into a weekly review queue — don't auto-file them or your backlog becomes noise.

Coverage baseline: confirm the DAST scan is authenticated (not just scanning the public pages), and measure which paths it covers. A DAST scan that only hits the homepage is not a security scan — it's a false confidence signal.