Day 84: DAST; project: fail the build on CVE/secret
DAST: testing the running thing, not just the code
Every gate so far analyzes code or artifacts statically. DAST (Dynamic Application Security Testing) attacks a *running* application (typically on staging) the way a real attacker would — sending malformed input, probing for injection, checking security headers — catching runtime-only issues that static analysis structurally cannot see (misconfiguration, actual request/response behavior).
dast:
runs-on: ubuntu-latest
needs: deploy-staging
steps:
- uses: zaproxy/action-baseline@v0.12.0
with:
target: 'https://staging.example.com'Phase 14 capstone project
Assemble the full pipeline: gitleaks → SAST (Semgrep) → SCA (Trivy fs) → build → image scan (Trivy) → SBOM (Syft) → sign (cosign) → GitOps repo update → (on staging) DAST (ZAP). The deliverable: a pipeline that genuinely fails the build on a real critical CVE or a deliberately committed fake secret — not just logs a warning.
Prove it actually blocks something
Commit a fake AWS-key-shaped string on a branch and open a PR — confirm gitleaks fails the check. Then add a deliberately old, CVE-laden dependency version and confirm Trivy fails the build too. A security pipeline that has never actually failed a build in testing is a pipeline you haven't verified.
Phase 14 complete — you should now be able to
Why can't SAST alone replace DAST in a security pipeline?
