Secure SDLC: where each scanner earns its keep
SAST, DAST, SCA, secrets scanning, IaC scanning. What each finds, what it misses, where it runs in the pipeline, and how to keep developers from ignoring all of it.
FREELesson·20 min read·Intermediate → Advanced
DevSecOpsSASTSCApipeline
01The scanner map
✓What you will learn
- Place each scanner at the right pipeline stage
- Explain false-positive budgets and why blocking builds blindly fails
- Design paved roads so the secure path is the default
| Scanner | Finds | Misses | Where |
|---|---|---|---|
| Secrets scanning | Keys and tokens in commits | Secrets in env vars at runtime | Pre-commit + CI + history scan |
| SCA | Vulnerable dependencies, licences | Whether the vulnerable function is reachable | CI, plus continuous re-scan of deployed SBOMs |
| SAST | Injection patterns, dangerous APIs | Authz logic, business flaws | CI on PRs, tuned rule set |
| IaC scanning | Public buckets, open security groups | Runtime drift | CI on Terraform / Helm |
| DAST | Runtime issues: headers, auth bypass, SSRF | Anything behind complex flows | Staging, nightly |
| Container scanning | OS package CVEs in images | App-level bugs | Registry admission |
02Making it stick
- Block on few things, loudly: leaked secrets, critical reachable CVEs with fixes, public storage. Warn on the rest.
- Fix at the source: a golden base image, a shared auth library, a Terraform module with safe defaults. One fix, every team.
- Measure MTTR by severity, not raw finding counts. Counts reward noisy tools.
- Security champions: one engineer per team who triages findings and owns the backlog.
“How to say it in the room
"I'd rather have four rules developers trust than four hundred they ignore. Start with secrets and critical reachable CVEs blocking, everything else as PR annotations, and widen the blocking set as the false-positive rate proves out."
Finished this one?
Tick it and it shows as done on the roadmap and the course.