DevSecOps is DevOps with security automated into every stage instead of bolted on at the end. See the anatomy of a secure pipeline, where each check belongs, and the one rule that makes it work: fast feedback.
Traditional security was a gate at the end: build for months, then a security team runs a scan and blocks the release. DevSecOps moves those checks left — into the developer's commit, the pull request, and the deploy — and expresses them as code that runs automatically. The security engineer's job shifts from "run the scan" to "own the pipeline that runs every scan on every change."
Old model (slow, adversarial):
code ....... months ....... [SECURITY GATE] -> findings -> rework -> ship
DevSecOps (fast, automated):
commit --> PR --> merge --> deploy
| | | |
secret SAST build+ DAST /
scan deps image runtime
scan scan checks
Same checks — but automated, per-change, and owned by the team
that writes the code. Security becomes everyone's job because the
pipeline makes it unavoidable.Each class of check has a natural home based on what it needs and how fast it must be. Cheap, fast checks run early and often (pre-commit, PR); expensive checks that need a running app run later (staging). Put a check too late and feedback is slow; put it too early and it needs inputs that do not exist yet.
Stage Check Needs Speed
pre-commit secret scan, lint the diff seconds
PR / push SAST, dependency (SCA) scan, the code 1-3 min
IaC scan, unit+security tests
build container image scan, SBOM a built image 1-2 min
pre-deploy policy gate (thresholds) all results seconds
staging DAST, smoke security tests a running app 5-15 min
production runtime detection, monitoring live traffic continuous
Rule: the earlier a bug is caught, the cheaper it is to fix.A security pipeline lives or dies on two properties: it must be fast enough that developers do not route around it, and its failures must be trustworthy enough that a red build means a real problem. A slow, noisy pipeline gets disabled — and a disabled pipeline secures nothing. Every design choice in this course serves those two properties.
Two ways a security pipeline dies:
TOO SLOW devs wait 40 min for a scan -> they merge around it,
disable it "just this once", or stop pushing small PRs.
Fix: run fast checks on PR, slow checks nightly/on merge.
TOO NOISY 90% of failures are false positives -> devs learn that
red = ignore -> a real finding sails through.
Fix: tune rules, baseline existing debt, fail only on
NEW, high-confidence, high-severity findings.
Speed + signal. Protect both, or the pipeline becomes theater.Here is the GitHub Actions skeleton the rest of the course fills in, stage by stage. Each subsequent lesson adds one job — secret scanning, SAST, dependency and container scanning, DAST — and the final lesson adds the policy gate and hardens the workflow itself. Read it now as a map; you will implement each piece.
# .github/workflows/security.yml
name: security
on:
pull_request:
push:
branches: [main]
permissions:
contents: read # least privilege by default (lesson 6)
jobs:
secrets: {} # lesson 2 — gitleaks
sast: {} # lesson 3 — Semgrep
deps: {} # lesson 4 — dependency (SCA) scan
image-scan: {} # lesson 4 — Trivy on the built image
dast: {} # lesson 5 — OWASP ZAP against staging
gate: {} # lesson 6 — enforce thresholds, block deploy