DevSecOps Practice Hub

Dynamic Application Security Testing

Probe a running application from the outside to find vulnerabilities that only appear at runtime.

IntermediateDASTApplication

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Test Dynamic testing, integration security tests and security gates.
  • Deploy Policy enforcement, admission control and infrastructure security.

Overview

Dynamic testing exercises a deployed instance of the application over HTTP. Because it observes real responses, it detects configuration issues, authentication flaws and injection behaviour that static analysis cannot see.

Why it matters

Runtime behaviour depends on configuration, middleware and infrastructure. DAST validates the deployed system as an attacker would experience it, closing the gap between reviewed code and running service.

How it works

  1. 01The scanner crawls or is fed an OpenAPI specification to discover endpoints.
  2. 02Active checks send crafted payloads and evaluate responses.
  3. 03Authenticated scans use a scripted login or injected session token.
  4. 04A report is produced with reproduction requests for each finding.

Common tools

OWASP ZAPBurp SuiteNucleiGitLabKubernetesDocker

Implementation examples

yamlOWASP ZAP baseline scan
dast:  stage: test  image: ghcr.io/zaproxy/zaproxy:stable  script:    - zap-baseline.py -t "$STAGING_URL" -r zap-report.html -I  artifacts:    paths: [zap-report.html]
The baseline scan is passive and fast, suitable for every pipeline run. Full active scans are noisy and belong on a schedule against a dedicated environment.

Security considerations

  • Only scan environments you are authorised to test; never point active scans at production without approval.
  • Active scans can create data, send email or trigger workflows — use disposable test data.

Best practices

  • Run baseline scans per merge request and full scans nightly.
  • Feed the scanner an API specification instead of relying on crawling.
  • Keep a dedicated, resettable test environment.

Common mistakes

  • Scanning production and triggering rate limits or alerts.
  • Running unauthenticated scans only, missing most of the attack surface.

Learning resources