chapter 05

Lessons Learned

What's left after running all three gates end to end against a real target, and where this lab could go from here.

DAST doesn't behave like the other two gates

Gitleaks and SonarCloud make sense running on every Pull Request, because every PR has a different diff — new code, new commits, a new surface to evaluate. A DAST scan against a fixed target doesn't have that property: Juice Shop turns up the same 8 findings regardless of which commit triggered the scan, because the target hasn't changed.

Running pre-deploy-dast.yml on every push, like the other two workflows, left the repository permanently "red" in Actions — technically correct (the gate is working), but a bad signal to anyone looking from the outside, who has no way to tell "gate working as expected" apart from "broken pipeline" just from the red X.

When each gate is worth it

Gate	Worth it when	Cost of always running it
Secret scanning	Always — it's cheap, fast, and the cost of a leaked secret is high	Very low (seconds)
SAST / Quality Gate	Every PR, evaluating only new code — retroactive on legacy code generates too much noise to be actionable	Low (seconds to a few minutes)
DAST	On demand, or scheduled against a real staging environment — not on every commit	High (minutes) and not very informative if repeated without the target changing

Document exceptions, don't silence them

The case of the .gitleaks.toml test fixture (test/fixtures/fake-credentials.js) reinforced a simple principle: every exception to a security gate should come with a line explaining why it's safe — not just the path being silently ignored. That matters both to whoever reviews the PR and to whoever, months later, finds the exception without remembering the original context.

What got proven

All three gates blocked real, non-simulated findings against a real target:

• Gitleaks — blocked a correctly-formatted test AWS credential (chapter 03).
• SonarCloud — failed the Quality Gate on Security Rating for code with a hardcoded credential, SQL injection, and eval().
• OWASP ZAP — found 8 real security configuration problems on the running Juice Shop.

All the code, workflows, and evidence are public at github.com/RootKaito/secure-pipeline-poc.

Where to take it from here

• DefectDojo — consolidate the findings from all three gates into a single dashboard, instead of three separate reports. Deliberately cut from v1; it only earns its own chapter if it turns out to be needed.
• Scheduled ZAP — instead of only manual triggering, run it weekly against a real staging environment (not an ephemeral runner container).
• More SonarCloud rules — this lab proved the gate with a deliberately obvious case; a natural next step is testing against subtler vulnerabilities.