This skill covers integrating OWASP ZAP (Zed Attack Proxy) for Dynamic Application Security Testing in CI/CD pipelines. It addresses configuring baseline, full, and API scans against running applications, interpreting ZAP findings, tuning scan policies, and establishing DAST quality gates in GitHub Actions and GitLab CI.
Instrucciones de origen · Vista previa de solo lectura
name
integrating-dast-with-owasp-zap-in-pipeline
description
This skill covers integrating OWASP ZAP (Zed Attack Proxy) for Dynamic Application Security Testing in CI/CD pipelines. It addresses configuring baseline, full, and API scans against running applications, interpreting ZAP findings, tuning scan policies, and establishing DAST quality gates in GitHub Actions and GitLab CI.
When testing running web applications for vulnerabilities like XSS, SQLi, CSRF, and misconfigurations
When SAST alone is insufficient and runtime behavior testing is required
When compliance mandates dynamic security testing of web applications before production
When testing APIs (REST/GraphQL) for authentication, authorization, and injection flaws
When establishing continuous DAST scanning in staging environments before production deployment
Do not use for scanning source code (use SAST), for scanning dependencies (use SCA), or for infrastructure configuration scanning (use IaC scanning tools).
Common Misconfigurations & Verification
Baseline mistaken for full coverage:zaproxy/action-baseline (and zap-baseline.py -I) only spiders and passive-scans — it never fires XSS/SQLi payloads. Use action-full-scan/zap-full-scan.py (active scan) for injection classes, and accept the 30+ minute runtime.
Scanning behind auth as anonymous: without a context/auth script ZAP only sees the login page and reports "clean." Supply a context file, replay an authenticated session token, and confirm the spider count covers post-login URLs.
Gate that can't fail:-I (allow_issue_writing: false / informational-only) plus cmd_options without -w/exit handling means the job stays green on a HIGH finding. Drive the gate off the JSON report (FAIL rows in report_json.json) or a non-zero ZAP exit.
API scan with no spec: pointing action-api-scan at a base URL instead of the OpenAPI/GraphQL definition leaves most endpoints untested. Pass target: .../openapi.json with format: openapi.
rules.tsv silently over-suppressing: an IGNORE line (e.g. 40012 IGNORE) hides reflected XSS forever. Review the tsv each release and keep injection rules at FAIL.
Verify by introducing a finding: deploy a build with a reflected ?q=<script> sink to staging, run the full scan, and confirm alert 40012 appears and the pipeline blocks. A scan that stays green on a planted XSS is misconfigured.
Prerequisites
OWASP ZAP Docker image or installed locally (zaproxy/zap-stable or zaproxy/action-*)
Running target application accessible from the CI/CD runner (staging URL or Docker service)
ZAP scan rules configuration (optional, for tuning)
OpenAPI/Swagger specification for API scanning (optional)
Workflow
Step 1: Configure ZAP Baseline Scan in GitHub Actions
# .github/workflows/dast-scan.ymlname:DASTSecurityScanon:deployment_status:workflow_dispatch:inputs:target_url:description:'Target URL to scan'required:truejobs:zap-baseline:name:ZAPBaselineScanruns-on:ubuntu-latestservices:webapp:image:${{github.repository}}:${{github.sha}}ports:-8080:8080options:--health-cmd="curl-fhttp://localhost:8080/health"--health-interval=10s--health-timeout=5s--health-retries=5steps:-uses:actions/checkout@v4-name:ZAPBaselineScanuses:zaproxy/action-baseline@v0.12.0with:target:'http://webapp:8080'rules_file_name:'.zap/rules.tsv'cmd_options:'-a -j'allow_issue_writing:false-name:UploadZAPReportif:always()uses:actions/upload-artifact@v4with:name:zap-baseline-reportpath:report_html.html
Step 2: Configure ZAP Full Scan for Comprehensive Testing
Dynamic Application Security Testing — tests running applications by sending requests and analyzing responses
Baseline Scan
Quick passive scan that spiders the application without active attacks, suitable for CI/CD
Full Scan
Active scan including attack payloads for XSS, SQLi, and other injection vulnerabilities
API Scan
Targeted scan using OpenAPI/Swagger specs to test all documented API endpoints
Spider
ZAP's crawler that discovers application pages and endpoints by following links
Active Scan
Phase where ZAP sends attack payloads to discovered endpoints to find exploitable vulnerabilities
Passive Scan
Analysis of HTTP responses for security headers, cookies, and information disclosure without sending attacks
Scan Policy
Configuration defining which attack types to enable and their intensity levels
Tools & Systems
OWASP ZAP: Open-source web application security scanner for DAST testing
zaproxy/action-baseline: GitHub Action for ZAP passive baseline scanning
zaproxy/action-full-scan: GitHub Action for ZAP active full scanning
zaproxy/action-api-scan: GitHub Action for API-focused scanning with OpenAPI support
Nuclei: Alternative vulnerability scanner with template-based detection for CI/CD integration
Common Scenarios
Scenario: Integrating DAST into a Staging Deployment Pipeline
Context: A team deploys to staging before production and needs automated DAST scanning between stages to catch runtime vulnerabilities.
Approach:
Add a DAST job in the pipeline that triggers after successful staging deployment
Run ZAP baseline scan first for quick passive feedback (2-5 minutes)
Follow with a targeted API scan using the application's OpenAPI specification
Configure rules.tsv to FAIL on critical findings (XSS, SQLi) and WARN on headers/cookies
Upload ZAP reports as pipeline artifacts for review
Block production deployment if any FAIL-level findings are detected
Schedule weekly full scans against staging for deeper coverage
Pitfalls: ZAP full scans can take 30+ minutes and may overwhelm staging servers with attack traffic. Use baseline scans in CI and full scans on schedule. Running DAST against production without coordination can trigger WAF blocks and incident alerts.
