ZAP Web Security Scanner - Hardened DAST for Web Apps, APIs

What is ZAP

ZAP (Zed Attack Proxy) is the most widely used open-source dynamic application security testing scanner. It finds vulnerabilities in a running web application or API the way an attacker would - by sending real requests and analysing the responses - rather than by reading source code. A spider maps the application, passive rules inspect every response as it passes, and active rules probe for injection, cross-site scripting, broken access control, insecure deserialisation, path traversal and misconfiguration. ZAP imports OpenAPI, SOAP and GraphQL definitions to scan APIs that have no browsable UI, scores findings by confidence and risk, and exports HTML, JSON, XML or Markdown reports. Everything it does is driven by a documented REST API, which is what makes it the standard choice for automated security testing inside a build pipeline.

Why self-host ZAP

A DAST scanner sees your application exactly as an attacker would, which means its findings are a map of how to compromise you. Running the scanner inside your own network keeps that map, the traffic it captures and the credentials it authenticates with entirely within your own boundary and jurisdiction - relevant both for GDPR and for contractual rules on penetration-test data. Self-hosting also removes per-scan and per-application pricing, so scanning every branch on every commit costs compute rather than licence, and it lets the scanner reach internal staging environments that a hosted service cannot see at all.

What this VM image adds

Security hardening:

• Per-instance API key - generated at first boot, never baked into the image; every scanner view and action requires it
• Scanner bound to loopback - the daemon listens on 127.0.0.1 only; nginx terminates TLS on 443 and is the sole path in
• Not usable as an open proxy - ZAP doubles as an intercepting proxy, so the reverse-proxy configuration pins the upstream host and the appliance refuses to relay traffic to third-party sites
• No outbound calls on first boot - scan rules are baked into the image and usage telemetry is switched off; the VM works in an egress-restricted subnet
• CVE scan - every image is scanned for vulnerabilities with Trivy before release, and the bundled Java components are additionally checked against the OSV advisory database
• UFW firewall - only 22 and 443 open; the scanner port is never externally reachable
• fail2ban - SSH brute-force protection
• AppArmor - mandatory access control

OS hardening (CIS Level 1):

• CIS Level 1 hardened - CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
• auditd - system call auditing for critical paths
• SSH hardening - PasswordAuthentication disabled, key-only access
• Kernel hardening - SYN cookies, ASLR, rp_filter, TCP BBR
• /tmp as tmpfs - nosuid, nodev, noexec
• Azure IMDS endpoints - egress rules pre-configured (169.254.169.254, 168.63.129.16)

Compliance artifacts (inside the VM):

• SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json
• CIS Conformance Report - OpenSCAP HTML at /etc/lynxroute/cis-report.html
• Tailored CIS profile - /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md
• Scan reports - HTML, JSON, XML and Markdown, generated on demand through the API

Quick Start

1. Deploy the VM from Azure Marketplace (Standard_D2s_v3 or larger recommended)
2. Restrict the network security group so port 443 is reachable only from your own address
3. SSH: ssh -i key.pem <username>@<PUBLIC_IP> (username set during VM creation, default: azureuser)
4. Read the API key: sudo cat /root/zap-credentials.txt
5. Open https://<PUBLIC_IP>/ and accept the self-signed certificate, or drive the scanner directly: curl -sk "https://<PUBLIC_IP>/JSON/spider/action/scan/?apikey=<KEY>&url=<TARGET>"
6. Replace the self-signed certificate with your own: sudo certbot --nginx -d your-domain.example.com

Only scan systems you own or have explicit written permission to test - active scanning sends real attack payloads.