OWASP ZAP Workflow and Automation: Baseline Scans vs Authenticated Crawl in a CTEM Loop

TL;DR

OWASP ZAP is a capable, open-source DAST engine, but the way most teams automate it — a two-minute zap-baseline.py job in CI — checks a small fraction of the real attack surface. A baseline scan is passive and usually unauthenticated; an authenticated crawl plus active scan reaches protected functionality but is fragile: session expiry, MFA, CSRF tokens, rate limits, and WAFs all break it. CI integration is good at catching regressions in rules you already tuned, and poor at building an exposure inventory, ranking by exploitability, or remembering anything between builds. The loop only closes with validator-backed findings: reproduce the alert, capture request/response evidence, confirm exploitability and business context, assign an owner, then retest.

What this is

OWASP ZAP (Zed Attack Proxy) is an open-source dynamic application security testing (DAST) tool. It works by sitting between your browser or test client and the target application, then using that vantage point to discover URLs, submit parameters, and inject payloads. A "ZAP workflow" is the ordered sequence of jobs you run against a target: define scope, configure authentication, crawl, run passive rules, run active rules, generate a report, triage, and retest.

Automation in ZAP typically takes one of four shapes:

• zap-baseline.py — spider plus passive scan only. Runs in a minute or two, sends no attack payloads, and by default does not authenticate. It is a hygiene smoke test: security headers, cookie flags, exposed files, information leakage.
• zap-full-scan.py — spider plus active scan. Actively fuzzes parameters. Runtime ranges from minutes to hours depending on app size and how aggressively you throttle it.
• zap-api-scan.py — imports an OpenAPI, SOAP, or GraphQL definition and tests the API surface directly, which is far more reliable than hoping a crawler guesses your endpoints.
• The Automation Framework — a declarative YAML plan with ordered jobs (passiveScan-config, spider, ajaxSpider, activeScan, report, and others), environment-substituted variables, and explicit failure handling. If you maintain more than one application, this is the only sane way to keep ZAP reproducible.

The distinction that matters most in practice is not baseline versus full scan — it is unauthenticated versus authenticated coverage. An unauthenticated scan can only see what an anonymous visitor sees. Most of the interesting exposure — broken object-level authorization, role confusion, data leaks in account views — lives behind a login.

Why it matters

Web applications and APIs remain the dominant initial access path in breach reporting, and they are also the part of the stack that changes fastest. A weekly release cadence means the application a pipeline tested on Monday may not be the one running on Thursday.

Regulatory pressure has caught up. PCI DSS v4.0 expects scripted testing of public-facing applications and internal vulnerability scans as an ongoing control, not a pre-audit sprint. Frameworks like NIST SSDF and OWASP ASVS push teams toward repeatable, documented testing. The result: almost everyone now runs something automated in CI.

The problem is that scanning has become a checkbox. A green pipeline is read as "the app is secure," when in reality a baseline scan tests a narrow rule set against an unauthenticated crawl. Teams that graduate to authenticated full scans often hit the opposite failure: long runtimes, brittle sessions, and a pile of alerts nobody trusts. Then someone disables the job, and the coverage quietly goes to zero.

The missing piece is not more scanning. It is validation and prioritization — deciding which of the hundreds of signals actually represents exploitable, business-relevant exposure that a human should act on this week.

How it works

A realistic attacker sequence against a web application looks like this:

1. Map the surface. Enumerate hosts, fetch JavaScript bundles, pull endpoint names, and diff staging versus production.
2. Test unauthenticated access. Look for APIs that never enforced auth, debug endpoints, and verbose errors.
3. Get a legitimate low-privilege account. Registration is often open; free trials work fine.
4. Abuse object and function-level authorization. Change an ID, change a role, call an admin endpoint with a normal token.
5. Probe injection and deserialization paths on the parameters that reach a backend.
6. Abuse business logic — replay a coupon, skip a payment step, manipulate quantities.

ZAP maps onto steps 1, 2, and 5 reasonably well, and step 4 partially, if and only if the scan is authenticated. Here is where the workflow breaks:

• The crawl never reaches the page. If a route is only rendered by client-side JavaScript or sits behind a multi-step wizard, the traditional spider will not find it — and if the active scanner never sees a URL, it can never test it.
• The session dies mid-scan. Session tokens expire, CSRF tokens rotate, and "remember me" logic fails. When that happens, ZAP cheerfully continues scanning the login page and returns a clean report. The absence of findings is an artifact, not a result.
• The WAF absorbs the scan. A 403-heavy scan session produces empty findings and a false sense of assurance, plus a pile of blocked-request noise for the SOC.
• The flaw has no oracle. Logic abuse has no signature: the response is a valid HTTP 200 with a wrong business outcome. No DAST rule catches it.

This is why authenticated crawl quality — not scan rule count — is the real determinant of ZAP's value. And it is exactly the part that is hardest to keep working as applications evolve.

Detection and response

Hypothesis: a ZAP run reports clean because the session failed or the crawl never reached the interesting routes, not because the application is hardened. Confirm or reject it with coverage evidence rather than alert counts.

Good ZAP telemetry starts with what the tool already gives you. Every alert carries a name, risk level, confidence, CWE/WASC identifier, URL, affected parameter, the attack string sent, evidence from the response, remediation guidance, and references. Reports can be emitted as HTML, XML, JSON, or SARIF — SARIF being the useful one if you want findings to land in code scanning or a durable store rather than a CI artifact that expires.

Beyond raw alerts, track these coverage signals:

• Authenticated versus unauthenticated URL coverage. How many endpoints did the scan actually reach with a session versus without? A sudden drop is a broken context, not a hardening improvement.
• Crawl scope against known endpoints. Compare the URLs ZAP discovered with your OpenAPI specification, sitemap, or recorded traffic. A 30 percent gap means 70 percent of your app was never tested.
• Authentication failure detections. Watch logged-in/logged-out indicators and unexpected redirects to login. These should alert loudly, because a silently failed session invalidates the entire run.
• Alert counts per rule with confidence levels. High-confidence, low-noise rules belong in the gate; low-confidence rules belong in review.
• Suppression inventory. Every muted rule should have a documented reason and an owner, or your scan config becomes an archaeology project.
• Trend, not snapshots. New versus recurring versus remediated findings across runs, plus time-to-remediation per owner.

The structural gap is that ZAP output is finding-centric, not asset-centric. It does not know what the asset does for the business, who owns it, whether the CVE behind it is being exploited in the wild, or whether the target is production or a sandbox nobody cares about. Those are the questions that determine whether an alert becomes work.

What to do

1. Decide the job each scan is doing. A per-pull-request baseline scan is a regression tripwire. A scheduled authenticated full scan is coverage. Do not ask one to do both — you will get either slow pipelines or shallow assurance.
2. Move complex workflows into the Automation Framework. Versioned YAML plans in the repository, with parameters injected from CI secrets, beat shell scripts with twenty flags.
3. Configure authentication properly. Define a context with the right authentication method (form, JSON, script, or header), correct session management, verified logged-in and logged-out indicators, and explicit re-authentication. Use least-privilege dedicated test accounts.
4. Handle MFA deliberately. Either use API tokens for the test account, store a TOTP seed in the secret manager, or provide a test role in a non-production environment. Do not point a scanner at an MFA prompt and hope.
5. Seed the crawler instead of trusting it. Feed URLs from OpenAPI specs, sitemaps, and recorded proxy traffic. Enable the AJAX/browser spider for JavaScript-heavy apps.
6. Exclude destructive endpoints. Wire transfers, mass emails, delete operations, and payment flows should be excluded from active scanning — and the exclusion list should be reviewed like code.
7. Tune rules with documented rationale. Keep a suppression or allowlist file in the repository, and require a comment and a date for every entry.
8. Scan a safe environment first. Staging with production-like data and production-equivalent configuration beats production with rate limits and a nervous on-call engineer.
9. Fail the build narrowly. Gate on a small, agreed rule set at high confidence. Total alert count is a terrible gate — it breaks on the first noisy rule and gets disabled within a month.
10. Persist results outside the runner. Publish SARIF or JSON to durable storage so findings outlive the CI artifact and can be trended.
11. Validate before you ticket. Reproduce the finding manually, capture request and response evidence, confirm the impact, and check whether the component maps to something in CISA KEV or has a meaningful EPSS score.
12. Retest and close. Track time-to-remediation and re-run the specific rule against the specific endpoint. Closed tickets without retest evidence are wishes.

FAQ

Is the ZAP baseline scan enough for CI? As a regression tripwire on a small, agreed rule set, yes — it is fast, low-risk, and catches header and cookie regressions early. As an assurance statement about your application, no. It is passive, usually unauthenticated, and blind to everything behind a login.

How do I run ZAP against an authenticated application? Define a context with the correct authentication method (form-based, JSON-based, script-based, or header-based), the matching session management approach, and — critically — verified logged-in and logged-out indicators. Add a verification URL and re-authentication so expired sessions are detected rather than silently tolerated. Use a dedicated least-privilege test account with credentials injected from CI secrets, never committed to the repository.

Why does ZAP miss findings on single-page applications? The traditional spider follows links in HTML. If routing is handled in JavaScript, there is nothing to follow. Enable the browser-based AJAX spider, and seed the scan with URLs from your OpenAPI spec, sitemap, or recorded proxy traffic. A crawler can only test what it can reach.

How many false positives should I expect from ZAP? It depends heavily on your framework, the rule pack, and the confidence threshold you accept. Passive rules are generally cleaner than active ones. Rather than chasing zero false positives, build a per-rule tuning file with documented rationale, and treat confidence as a filter — then validate before ticketing.

Can ZAP test APIs? Yes. zap-api-scan.py and the Automation Framework can import OpenAPI, SOAP, and GraphQL definitions, which is far more reliable than crawling for endpoint discovery. Coverage of authorization logic — BOLA, BFLA, multi-step business flows — remains limited, so pair it with dedicated API surface testing.

How is CTEM different from just running ZAP scans? ZAP is a scanner: it produces signals about a target you name, for the duration of a run. Continuous Threat Exposure Management is a program: it discovers what you own, scans across network, web, API, TLS, and mail/DNS posture, validates findings so not every hit becomes an alarm, adds exploitability and business context, assigns ownership, and reports on remediation. You can run ZAP forever and still not have an exposure inventory.

How often should ZAP scans run? Baseline per pull request or nightly; authenticated deep scans on a schedule against staging and your most critical applications; API scans whenever the specification changes. Let change rate and asset criticality drive frequency — not whatever happens to fit inside a CI timeout.

Where this fits in a program

ZAP automation produces signals; a program turns them into decisions. Start with an attack surface inventory so scans target what you actually own. Add validation so a scanner hit is not treated as proof. Extend coverage with API surface testing and deeper web application testing for critical apps. Trusteed keeps inventory, findings, validation, and remediation status continuous, so each scan run adds history instead of expiring with the CI artifact.

Sources

• Trusteed CTEM platform — continuous threat exposure management for external and internal attack surface
• Trusteed tenant app — operator workflow for findings, validation, and remediation tracking
• Trusteed vulnerability intelligence blog — KEV and emergent-threat analysis for prioritization decisions
• OWASP ZAP documentation — scanning options, contexts, and authentication configuration
• ZAP Automation Framework — declarative YAML plans for reproducible scan workflows
• OWASP Web Security Testing Guide — the manual methodology DAST automation approximates
• NIST SP 800-115 — technical guide to information security testing and assessment
• CISA Known Exploited Vulnerabilities catalog — exploitation evidence that should change your remediation order