Dynamic Analysis in Practice

By chapter 6 you've already read your own code (SAST) and audited what you pulled in from someone else (SCA). This chapter attacks the thing you actually shipped — a live, running target — the way an external adversary would: no source access, just HTTP traffic and a browser. You'll stand up an OWASP ZAP baseline scan against a target you control, wire in the authentication and spidering setup that's the real difference between a scan that covers the app and one that quietly stalls at the login form, run a full active scan and a Burp Suite Dastardly pass, and learn to read an alert's risk and confidence before you file it. Every command here is one you can run today against a target you're authorized to test.

What this chapter tests, and where DAST sits in the blueprint

☺ Like you're 10: This chapter isn't a quiz about definitions — it's the part where you actually point a scanner at something and read what comes back.

Practical DevSecOps doesn't publish a percentage-weighted domain breakdown for the CDP the way a multiple-choice exam publishes "Domain 3 is 20% of the test" — its 5 live challenges blend these skills together against a running environment, a point the certifications page already makes plainly. What this course's own blueprint does instead is organize the underlying practice into 9 chapters that map onto that hands-on scope, and dynamic analysis is reliably one full challenge-equivalent of work on its own: standing up a scan correctly, authenticating it, and separating a real finding from noise — against a target that's actually running, not a diff sitting in a pull request.

That's also the structural reason DAST comes after static analysis and secrets detection in this blueprint rather than before it. Chapter 5 only needed a source tree — it could run in seconds, on every commit, before anything was deployed. This chapter needs a deployed target, because it isn't reading code at all; it's attacking behavior, and behavior only exists once something is running. If you haven't already read the conceptual split between SAST, DAST, and SCA, that page is the fifteen-minute primer this chapter assumes. What follows is the part that primer only summarizes: the actual commands, the actual YAML, and the actual judgment calls.

Stand up a baseline scan against a running target

☺ Like you're 10: A baseline scan is the burglar walking around and looking — it never actually tries a door, so it's safe to run against a house that's still occupied.

OWASP ZAP ships an official Docker image, and the fastest way to get a first result is its baseline scan script — a thin wrapper that spiders the target for a short, bounded window and then runs ZAP's passive scan rules against whatever traffic that spidering generated. "Passive" is the load-bearing word: baseline never sends an attack payload, it only inspects the requests and responses that ordinary crawling produced. That's exactly why it's the scan most teams wire in as a required PR or merge-gate check — it finishes in minutes and it's safe to point at almost anything, staging or otherwise.

docker run --rm -v $(pwd):/zap/wrk/:rw \
  -t zaproxy/zap-stable zap-baseline.py \
  -t https://staging.internal.example.com \
  -r zap-baseline-report.html \
  -J zap-baseline-report.json \
  -I

The -I flag tells the script not to fail the job on a WARN-level result — useful while you're first tuning a rule set, so a pipeline doesn't hard-block on day one before anyone has triaged anything. Once the rule set is tuned, drop -I and instead reclassify individual rules with a config file, so the exit code reflects a decision your team actually made rather than ZAP's untouched defaults:

# zap-rules.conf — one line per plugin ID, overriding the default WARN
# format: <plugin id>    <IGNORE|WARN|FAIL>    # optional comment
10202    IGNORE    # Absence of Anti-CSRF Tokens — this route is a public, read-only API
10096    FAIL      # Timestamp Disclosure — leaks internal clock skew we specifically track

Pass it with -c zap-rules.conf. Exact exit-code semantics have shifted a little across ZAP releases, so confirm the current mapping in ZAP's own docs before you wire a hard pipeline gate on a specific number — but the mental model (WARN by default, promote to FAIL for anything that should block, IGNORE for a confirmed false positive with a reason attached) has stayed stable for years.

Authentication: the setup that decides how much of the app gets tested

☺ Like you're 10: Without a key, the spider only ever finds the porch — the dashboard, the admin panel, and everything behind login stay invisible no matter how long it crawls.

Run either command above against a typical app with no authentication configured, and the spider finds the login page, maybe a marketing home page, maybe a health-check endpoint — three or four routes, total. The scan finishes fast, the report looks clean, and none of that means anything, because the spider never got past the front door. This is the single most common reason a DAST run "passes" and the app still ships a real vulnerability two clicks past login: nobody told the scanner how to log in.

ZAP's Automation Framework is the current, YAML-driven way to wire this up — it replaces hand-clicking through the desktop UI's authentication wizard with something you can commit to version control and diff. A context block defines the target, how to authenticate into it, and how ZAP verifies whether a given response came back logged in or logged out:

env:
  contexts:
    - name: "webapp"
      urls: ["https://staging.internal.example.com"]
      includePaths: ["https://staging.internal.example.com.*"]
      excludePaths: ["https://staging.internal.example.com/logout.*"]
      authentication:
        method: "form"
        parameters:
          loginPageUrl: "https://staging.internal.example.com/login"
          loginRequestUrl: "https://staging.internal.example.com/login"
          loginRequestBody: "username={%username%}&password={%password%}"
        verification:
          method: "response"
          loggedInRegex: "\\QWelcome back\\E"
          loggedOutRegex: "\\QPlease log in\\E"
      users:
        - name: "scanner"
          credentials:
            username: "dast-scanner@example.com"
            password: "$ZAP_SCANNER_PASSWORD"
jobs:
  - type: spider
    parameters: { context: "webapp", user: "scanner", maxDuration: 10 }
  - type: spiderAjax
    parameters: { context: "webapp", user: "scanner", maxDuration: 10 }
  - type: passiveScan-wait
    parameters: { maxDuration: 5 }
  - type: report
    parameters: { template: "traditional-html", reportDir: "/zap/wrk", reportFile: "zap-auth-report" }

Two details here do the actual work, and both are easy to skip under deadline pressure. First, verification — the loggedInRegex/loggedOutRegex pair — exists because a session can silently die mid-scan: a CSRF token mismatch, an idle timeout, a WAF rule that flags the scanner's traffic pattern. Without a verification check, ZAP has no way to notice that it fell back to an unauthenticated session, and everything scanned after that point quietly becomes "the same three public routes" again, just later in the run. Second, excludePaths keeps the spider away from /logout — a link-crawling spider treats a logout link exactly like any other link, and clicking it ends the session it just spent ten minutes building.

Not every app authenticates with a form POST. A token-based SPA or an API needs a script-based or HTTP-header authentication method instead — attaching a bearer token or JWT to every outgoing request via a ZAP script or the Automation Framework's script-based auth method. The exact configuration surface for that has moved around across ZAP add-on versions, so treat the shape here as the pattern to look for rather than something to copy verbatim without checking your installed version's current job list.

Spidering: traditional, AJAX, and OpenAPI-seeded coverage

☺ Like you're 10: One spider reads street signs; the other one actually walks into every store and opens every drawer — a modern app usually needs both, plus a map somebody already drew.

ZAP ships three distinct ways to discover what's there to attack, and picking only one is the second-most-common reason a DAST run under-covers a real application:

• Traditional spider — parses raw HTML for <a href> links and forms. Fast, and it's what the baseline scan uses by default. It's also blind to anything rendered client-side, which describes most of the interactive surface of a modern React, Vue, or Angular app.
• AJAX Spider — drives an actual headless browser (via Selenium, typically headless Firefox or Chrome) to click through the rendered UI and execute JavaScript, the same way a real user would. This is the one that actually discovers a single-page app's routes, because it's the only mode that runs the client-side router at all.
• OpenAPI / GraphQL import — for an API with no HTML to crawl in the first place, ZAP can import the spec directly and seed the sitemap from its documented operations, skipping discovery entirely. zap-api-scan.py -t https://staging.internal.example.com/openapi.json -f openapi -r zap-api-report.html runs an API-tuned scan against every operation in the file.

A pipeline that only ever runs the default traditional spider against a modern SPA backend will report a route count in the single digits against an app with dozens of real screens, and it will look exactly as clean as a thorough scan — clean reports and thin coverage are visually identical until you check the route count against what you know the app actually has.

Reading alert severity: risk × confidence, not just risk

☺ Like you're 10: One number says how bad it'd be if it's real; a second number says how sure the scanner is that it's real — you need both before you decide what to do.

Every ZAP alert carries two independent ratings, and treating them as one number is how teams end up either crying wolf or missing a real finding. Risk — Informational, Low, Medium, or High — describes how bad the underlying issue would be if it's genuinely exploitable. Confidence — Low, Medium, High, or Confirmed — describes how sure the scanner is that what it saw is actually that issue, as opposed to a heuristic false alarm. A few concrete alerts, and where they typically land:

The triage rule that keeps a team from either type of failure: a High risk, Low confidence alert gets manually verified before it blocks anything — reproduce it by hand, or it doesn't go in the release-blocking queue. A High risk, High/Confirmed confidence alert blocks the merge immediately; there's no ambiguity left to resolve. When you do confirm something is a false positive, suppress it narrowly — a ZAP Alert Filter scoped to that specific plugin ID and URL regex, with a written reason — never the whole plugin globally, or you've just blinded yourself to the next real instance of that same alert on a different route.

Going active: full scans, and where Burp Suite Dastardly fits in CI

☺ Like you're 10: This is the part where the burglar actually tries the doors — which is exactly why you only ever do it to a house you own.

Where baseline only listens, ZAP's full/active scan actually attacks: it takes every parameter the spider discovered and throws SQL injection payloads, XSS strings, path traversal sequences, and command-injection attempts at each one, then inspects the real response for evidence something worked. zap-full-scan.py -t https://staging.internal.example.com -r zap-full-report.html runs it end to end (spider, then active scan, then report) against whatever context and auth you've wired in the same way as the baseline run.

Burp Suite Dastardly, PortSwigger's free scanner built specifically for CI, trades thoroughness for speed and zero configuration. It runs a fixed, non-tunable scan — a fast crawl plus a curated set of high-confidence checks — and emits JUnit XML instead of a standalone report, so a DAST finding shows up next to your unit test failures in the same CI test-results UI instead of living in a separate silo nobody opens:

docker run --rm \
  -e BURP_START_URL="https://staging.internal.example.com" \
  -e BURP_REPORT_FILE_PATH="/dastardly/dastardly-report.xml" \
  -v "$(pwd)":/dastardly \
  public.ecr.aws/portswigger/dastardly:latest

Verify that image path on PortSwigger's own Dastardly docs before wiring it into a pipeline — registry locations move. What doesn't move is the positioning: Dastardly is explicitly a lightweight complement to a full ZAP or Burp Suite Professional scan, not a replacement for one. It has no authentication-configuration surface of its own, so it's best used on public-facing surfaces or paired with an already-authenticated ZAP run, not as your only DAST pass against an app that's mostly behind login.

Common exam traps in the DAST chapter

☺ Like you're 10: Most of the ways to lose points here aren't about not knowing DAST — they're about a scan that ran, looked fine, and quietly tested almost nothing.

Once ZAP and Dastardly hand you a stack of alerts, this chapter's job is done and the next one starts: turning risk-and-confidence-triaged noise into a fixed, tracked, closed ticket is exactly what vulnerability management & triage covers. For the API-only surfaces this chapter only touched briefly, API security in depth goes further, and if the hands-on itch isn't scratched yet, Part 6 of the capstone lab is this exact workflow against the pipeline you've been building across the course. Candidates who want to go past what any CDP challenge requires — real exploitation technique, not just scan-and-report — should look at offensive security for DevSecOps next.