Manual security testing catches obvious vulnerabilities, but systematically scanning every page, form, and API endpoint requires automated tools. OWASP ZAP (Zed Attack Proxy) is the most widely used free, open-source security scanner. It acts as a proxy between your browser and the application, analysing every request and response for vulnerabilities. More importantly, ZAP can be integrated into your CI/CD pipeline to catch security regressions automatically.
OWASP ZAP — Automated Security Scanning
ZAP operates in three modes: manual exploration (proxy mode), automated scanning (spider + active scan), and CI/CD integration (headless API mode).
# OWASP ZAP usage modes
ZAP_MODES = [
{
"mode": "1. Proxy Mode (Manual Exploration)",
"how": "Configure browser to use ZAP as proxy (localhost:8080). "
"Browse the application normally. ZAP records every request.",
"finds": "Passively detects: missing security headers, cookie flags, "
"information disclosure, mixed content (HTTP on HTTPS page)",
"effort": "Zero extra work — browse as normal; ZAP analyses in background",
},
{
"mode": "2. Automated Spider + Active Scan",
"how": "Point ZAP at a URL. Spider crawls all links. Active scan tests each "
"parameter with attack payloads (XSS, SQL injection, path traversal).",
"finds": "XSS, SQL injection, command injection, path traversal, CSRF, "
"remote file inclusion, server-side injection",
"effort": "Start a scan and wait 10-60 minutes depending on site size",
},
{
"mode": "3. CI/CD Integration (ZAP Docker + API)",
"how": "Run ZAP in Docker as part of your CI pipeline. Use the ZAP API "
"or baseline scan script to scan automatically after deployment.",
"finds": "Same as mode 2, but automated and repeatable on every build",
"effort": "One-time setup; runs automatically on every deployment",
},
]
# ZAP CI/CD integration example
ZAP_CICD = """
# GitHub Actions — ZAP baseline scan
name: Security Scan
on:
push:
branches: [main]
jobs:
zap-scan:
runs-on: ubuntu-latest
steps:
- name: ZAP Baseline Scan
uses: zaproxy/action-baseline@v0.12.0
with:
target: 'https://staging.yourapp.com'
rules_file_name: '.zap/rules.tsv' # Custom rule config
fail_action: true # Fail pipeline on high-risk findings
- name: Upload ZAP Report
uses: actions/upload-artifact@v4
if: always()
with:
name: zap-report
path: report_html.html
"""
# Other security testing tools
SECURITY_TOOLS = [
{
"tool": "OWASP ZAP",
"type": "DAST (Dynamic Application Security Testing)",
"cost": "Free, open source",
"best_for": "Automated web vulnerability scanning in CI/CD",
},
{
"tool": "Burp Suite",
"type": "DAST + manual proxy",
"cost": "Community Edition (free), Professional (paid)",
"best_for": "Manual penetration testing with advanced interception",
},
{
"tool": "npm audit / pip audit",
"type": "SCA (Software Composition Analysis)",
"cost": "Free, built into package managers",
"best_for": "Detecting known vulnerabilities in dependencies",
},
{
"tool": "Snyk / Dependabot",
"type": "SCA with auto-fix",
"cost": "Free tier available",
"best_for": "Automated dependency vulnerability detection and PR creation",
},
{
"tool": "SonarQube",
"type": "SAST (Static Application Security Testing)",
"cost": "Community Edition (free), Enterprise (paid)",
"best_for": "Finding security issues in source code without running the app",
},
]
print("ZAP Modes:")
for mode in ZAP_MODES:
print(f"\n {mode['mode']}")
print(f" How: {mode['how']}")
print(f" Finds: {mode['finds']}")
print("\n\nSecurity Testing Tools:")
for tool in SECURITY_TOOLS:
print(f"\n {tool['tool']} ({tool['type']})")
print(f" Cost: {tool['cost']}")
print(f" Best for: {tool['best_for']}")
Note: DAST tools (ZAP, Burp Suite) test the running application from the outside — they send requests and analyse responses, just like an attacker would. SAST tools (SonarQube) analyse source code without running the application — they find vulnerabilities in the code structure. SCA tools (npm audit, Snyk) check your dependencies for known CVEs. A comprehensive security strategy uses all three: SAST in the IDE (shift left), SCA in CI (dependency checking), and DAST after deployment (runtime scanning).
Tip: Start with the ZAP baseline scan (
zaproxy/action-baseline GitHub Action) — it runs a passive scan that checks for missing security headers, cookie misconfigurations, and information disclosure without sending any attack payloads. This is safe to run against any environment (even production) because it only analyses existing responses, not actively attacks the application. Add it to your CI pipeline in 10 minutes for instant security visibility.Warning: Active ZAP scans (spider + active scan) send attack payloads to the application — SQL injection strings, XSS payloads, and path traversal attempts. These can trigger WAF (Web Application Firewall) alerts, lock user accounts, create junk data, and in rare cases cause application crashes. Only run active scans against dedicated security testing environments, never against production or shared staging.
Common Mistakes
Mistake 1 — Running active security scans against production
❌ Wrong: Pointing ZAP’s active scanner at the production URL — triggers security alerts, potentially corrupts data, and may violate policies.
✅ Correct: Running active scans against a dedicated security testing environment. Using only passive scans (baseline) against staging or production.
Mistake 2 — Treating security scanning as a one-time activity
❌ Wrong: Running ZAP once before launch and never again.
✅ Correct: Integrating ZAP baseline scans into CI/CD so every deployment is automatically scanned. Running full active scans quarterly or before major releases.