M01: DevSecOps Mindset & Principles
This module frames DevSecOps as a culture problem before it is a tooling problem. Tooling without buy-in produces theater: green dashboards, real vulnerabilities. The goal of this module is to give you the vocabulary and the arguments to defend security investment inside an engineering org that measures throughput.
Learning Objectives
By the end of this module you should be able to:
- Define DevSecOps in one sentence that a CFO would accept
- Explain the difference between shift-left and bolt-on security
- Name the three cultural anti-patterns that predict pipeline-security failure
- Map the “shared responsibility” model onto a concrete CI/CD pipeline
- Identify which principle is violated by a given pipeline smell
1. What DevSecOps Actually Is
DevSecOps is the integration of security practices into the DevOps delivery pipeline such that security becomes a continuous, automated property of the system rather than a gate at the end of release.
Three load-bearing words:
- Integration — security is in the loop, not next to the loop
- Pipeline — security rides the same conveyor belt as features
- Property — secure-by-default, not secure-by-audit
If your security tooling requires human intervention to function, you do not have DevSecOps. You have DevOps with a security review board bolted on. That model worked at 4 deploys per year. It does not work at 40 deploys per day.
The Three Eras
| Era | Security lives in… | Cadence | Failure mode |
|---|---|---|---|
| Pre-2010 | A separate team, post-release | Annual audit | Findings arrive after deploy |
| 2010–2018 | A gate before production | Quarterly | Bottleneck, tickets accumulate |
| 2018–present | The pipeline, continuously | Per commit | Alert fatigue if poorly tuned |
We are firmly in era three. Modules M02–M20 build the technical depth. This module gives you the cultural foundation to make those modules actually run in a real org.
2. The Shift-Left Principle
Shift-left means moving security activity earlier in the development lifecycle. Earlier is cheaper. The industry rule of thumb is that a vulnerability found in design costs 10× less to fix than one found in production, and a vulnerability found in production can cost 100× more once you count breach response, customer notification, and reputation.
Cost-of-fix (log scale, illustrative)
^
| * * production
| * *
| * *
| * *
| * *
| * *
| * *
| * *
| * * staging
| * *
| * *
| * *
| * * integration
| * *
| * * commit
+-------------------------------------------> Phase
design code build test stage prod
Shift-Left Is Not Just “Run Scanners Earlier”
A common misunderstanding: a team runs Trivy in CI and declares they have shifted left. They have not. Shift-left is a property of the workflow, not a property of the scanner.
True shift-left means:
- Developers see security feedback on their own PRs, not in a quarterly report
- Security tests fail the build, not a release candidate
- Threat modeling happens during story design, not at architecture review
- The pipeline is the auditor; humans review exceptions, not the bulk
What Shift-Left Does Not Mean
- It does not mean developers become security engineers
- It does not mean every developer runs Burp Suite
- It does not mean removing the security team
- It does not mean “no security, just ship”
The security team’s job changes from “gatekeeper” to “platform builder” — they build the automated controls, maintain the policy-as-code, and consult on hard problems.
3. The Three Pillars
+--------------------+
| DevSecOps Core |
+---------+----------+
|
+----------------------+----------------------+
| | |
v v v
+---------------+ +-------------------+ +-------------------+
| Culture & | | Automation & | | Measurement & |
| Collaboration | | Tooling | | Feedback |
+---------------+ +-------------------+ +-------------------+
Shared ownership Pipelines-as-code Metrics that drive
across dev/sec/ops Policy-as-code behavior change
No-throw culture Fail-fast gates Mean time to remediate
Pillar 1: Culture & Collaboration
- Shared ownership — the team that owns the code owns its security
- Blameless post-mortems — when a vuln ships, ask “what control failed”, not “who forgot”
- Security champions — one engineer per squad who carries security context into planning
- Joint on-call — security incidents page developers, not just the security team
Pillar 2: Automation & Tooling
- Pipelines-as-code —
.github/workflows,Jenkinsfile,gitlab-ci.ymllive in git - Policy-as-code — Rego, Cedar, OPA bundles; no GUI-only rules
- Fail-fast gates — critical findings block the build, no override without review
- Idempotent controls — running the scan twice yields the same result
Pillar 3: Measurement & Feedback
- Lead time for changes — DORA metric, includes security gating time
- Vulnerability escape rate — vulns found in prod per release, target <5% of total findings
- Mean time to remediate (MTTR) — per severity tier
- Pipeline coverage — % of services with full security scan chain active
4. The Shared Responsibility Model
AWS made “shared responsibility” famous for cloud, but the model applies just as well to the pipeline. Every team owns a slice.
| Layer | Who owns it | What it means |
|---|---|---|
| Code & dependencies | Application team | SAST clean, SCA clean, no secrets in repo |
| Build environment | Platform team | Hardened runners, ephemeral, signed provenance |
| Container images | Application team | Distroless/minimal base, no root, SBOM emitted |
| CI/CD pipeline itself | Platform team | Pipeline files in git, OIDC auth, no long-lived keys |
| Deployment target | Platform + SRE | Network policies, PSA enforced, admission controls |
| Runtime | SRE | Falco/Wazuh rules, anomaly detection, response runbooks |
| Compliance reporting | Security team | Evidence collection, audit trail, exception register |
The boundary is explicit. The handoff is automated. There is no “I thought the other team was doing it.”
5. The Three Cultural Anti-Patterns
These three patterns predict pipeline-security failure with depressing consistency. If you see one in your org, fix it before adding more scanners.
Anti-Pattern 1: Security as Finders-Keepers
The security team finds issues, files tickets, and waits. Developers close tickets without understanding the root cause. Findings are treated as the security team’s KPI, not the engineering org’s KPI.
Symptom: the backlog of security tickets grows faster than the rate of fixes.
Fix: make the engineering org own MTTR. The security team’s KPI becomes “reduce severity-weighted finding count” — a leading indicator of the engineering org’s health.
Anti-Pattern 2: The Hero Auditor
One senior engineer reads every PR for security issues. The org scales linearly with their attention. They go on vacation, the gates collapse.
Symptom: PRs sit for 2+ days waiting on the security reviewer.
Fix: codify what the hero knows into scanners + policy-as-code. The hero’s value moves from “reviewer” to “rule author.”
Anti-Pattern 3: The Vanity Dashboard
The security team has a beautiful Grafana dashboard. Nobody outside security looks at it. Findings on the dashboard do not block deploys, do not page anyone, and do not appear in engineering standups.
Symptom: leadership asks “are we secure?” and the only answer is “the dashboard is green.”
Fix: integrate the metrics into the engineering org’s reporting. Make the same data visible to engineering managers, with a one-line summary: “X critical findings open > 30 days.”
6. A Day in a Shift-Left Pipeline
Concrete walkthrough of what shift-left looks like end to end.
07:42 Developer pushes a PR adding a new HTTP handler
07:42 Pre-commit hook (gitleaks) blocks the commit: API key detected
07:43 Developer removes the secret, references Vault path instead, re-commits
07:43 PR opened; CI begins
07:44 SAST (Semgrep) runs → 0 high/critical
07:45 SCA (Trivy fs) runs → 1 medium CVE in indirect dep, fails policy
07:45 Developer is paged in the PR comment, opens Dependabot PR to bump
07:46 Container build begins; SBOM generated and signed (cosign)
07:48 Image scan (Trivy image) → 0 critical; passes gate
07:48 Sign-off: cosign verify passes; provenance attached
07:49 Merge enabled; deploys to staging via Argo CD
08:15 DAST (ZAP baseline) runs against staging
08:30 Findings routed to Jira with severity, file, fix suggestion
Notice: zero human security review, zero scheduled meetings, zero email threads. The pipeline is the auditor.
7. Common Objections and Responses
| Objection | Response |
|---|---|
| ”Developers don’t have time to learn security” | They don’t have to. They need to know which scanner output matters and how to read a finding. Modules M02–M04 cover this. |
| ”We’ll slow down the build with all these scans” | Parallelize. SAST/SCA/secrets typically add 60–120s when run in parallel. Module M08 covers scan optimization. |
| ”False positives will kill us” | Tune the rule set in week 1; budget 1 engineer-week per scanner for the first 90 days. Module M11 covers tuning. |
| ”Auditors won’t accept automated controls” | They will, with evidence. SBOM, signed provenance, scan logs, exception register. Module M18 covers audit evidence. |
| ”We tried shift-left and it just shifted the work, not the work” | That’s a tooling problem. If finding a vuln takes 10 minutes to triage, your tooling is wrong. Module M07 covers triage. |
8. Your Stack in This Wiki
| Component | Where it lives in this wiki |
|---|---|
| Trivy (container/SCA) | Covered in M09-container-image-scanning, M08-dependency-scanning |
| Gitleaks (secrets) | M06-secrets-detection |
| Semgrep (SAST) | M05-static-analysis-sast |
| Sigstore/cosign | M14-supply-chain-attestations |
| Wazuh (runtime SIEM) | Out of scope — see README |
| OPA / Kyverno | M15-policy-as-code |
| n8n (workflow auto) | Out of scope — see automation |
9. Self-Check
Before moving to M02, answer these in writing:
- In your current org, who owns the security of a Terraform module? Who should own it?
- Pick a recent incident (yours or public). Which cultural anti-pattern above was visible in the post-mortem?
- What is the smallest change you could make this week that would shift one security check earlier in the pipeline?
10. The Economics: Why This Pays
A typical org’s cost model:
| Activity | Cost of doing it well | Cost of skipping it |
|---|---|---|
| SAST on every PR | 0.1 FTE for tuning + 5s/PRD in CI | One breach from SAST-detectable vuln: 50M |
| Secrets prevention | 0.05 FTE for gitleaks config | 4-minute window → key compromise: 10M |
| SCA / Dependabot | 0.2 FTE for triage | One Log4Shell-class dep: 100M |
| Container image hardening | 0.1 FTE for base images | One RCE in container: 10M |
| OIDC for pipeline | 0.2 FTE initial + 0.05 FTE ongoing | Static key leak: 10M |
| Runtime detection | 0.5 FTE for Falco + Wazuh tuning | Mean dwell time of 200+ days: $5M+ |
The math: 1–2 FTE-years of security engineering prevents 1–2 incidents per decade at industry-average cost. The pipeline is a positive-NPV investment even before you count the brand damage and the regulatory fines.
The “Cost of the Pipeline” Trap
A common objection: “we cannot afford the pipeline.” The unstated alternative: the cost of not having the pipeline is the cost of an incident. The right question is “what is the cost of doing this, vs. the cost of doing nothing, vs. the cost of a control that fails to do its job?”
Most orgs under-invest in security because the cost is visible (headcount) and the benefit is invisible (incidents that did not happen). A security team that succeeds looks like it overspent. A security team that under-spent looks like it was efficient — until the breach.
11. The People Problem
Tools are the easy part. The hard part is the people. Three roles that make or break DevSecOps:
The Security Champion
Embedded in each product squad. Not a separate role; an engineer with 10% time allocated to security. Carries the security context from the security team into the squad. Reviews SEC- criteria in grooming. Is the first reviewer for security-sensitive PRs.
The Platform Engineer
Owns the paved road. The CI templates, the module library, the default policies. If the paved road is good, the security team is invisible. If the paved road is missing, every squad reinvents security badly.
The Auditor Translator
The person who can map a control to evidence to a framework. Often the security lead. Without this role, audit time is a scramble.
12. Maturity Self-Assessment
Score your org on each dimension. 0 (no), 1 (partial), 2 (yes).
| Dimension | Score (0–2) |
|---|---|
| DevSecOps culture is shared, not a separate team | |
| Threat modeling is done in grooming, not in design review | |
| Security criteria are on every story | |
| Engineers can name the pipeline’s scanners without checking | |
| The security team measures engineering, not itself | |
| Runbooks exist for the top 10 alerts | |
| Postmortems are blameless and ship improvements | |
| Evidence is collected continuously, not at audit time | |
| The paved road is the default; off-road is the exception | |
| Leadership can answer “are we secure?” with a one-line number |
Total / 20:
- 0–6: Ad hoc
- 7–13: Foundational
- 14–18: Mature
- 19–20: World class
14. The First 30 Days: A Concrete Plan
The 30-day plan for a team starting from zero. The goal: ship a Tier 1 pipeline that catches the most common issues.
Days 1–5: Foundation
- Adopt pre-commit framework
- Add gitleaks pre-commit hook (M06)
- Add Semgrep pre-commit hook with
p/security-audit(M05) - Document the threat model 4Q in the story template (M02, M04)
- Identify the security champion in each squad (M01)
Days 6–10: PR-time Scans
- Add Semgrep to PR CI (M05)
- Add Trivy filesystem scan (M07) to PR CI
- Add Checkov (M10) for Terraform PRs
- Add a “SEC- prefix” section to the story template (M04)
- Set up Renovate or Dependabot (M07)
Days 11–20: Build Pipeline
- Migrate the first 3 Dockerfiles to multi-stage, distroless (M09)
- Add image scan to the build pipeline (M09)
- Generate SBOM at build (M08)
- Sign images with cosign keyless (M13)
- Set up the paved-road module library (M10)
Days 21–30: Deploy Gates
- Configure OIDC for the prod-deploy role (M12)
- Set up Kyverno in audit mode (M15)
- Add admission control to require signed images (M13, M15)
- Document the controls in the security policy (M03)
After 30 days, the team has:
- Pre-commit secrets + SAST
- PR-time SAST, SCA, secrets, IaC scan
- Build-time image scan + SBOM + signing
- Deploy-time admission control
- Tier 1 SSDLC posture
The next 30 days move toward Tier 2.
15. The First Quarter: Tier 2
The 90-day plan to Tier 2:
- Month 1 — Foundation + PR-time scans (above)
- Month 2 — Build pipeline + signing + SBOM
- Month 3 — Deploy gates + admission control + first IR runbook
After 90 days, the team has the Tier 2 SSDLC. The next quarter moves toward Tier 3.
16. The First Year: Tier 3
The annual plan to Tier 3:
- Quarter 1 — Tier 1 (M03)
- Quarter 2 — Tier 2 (M03)
- Quarter 3 — Tier 2 stable; begin Tier 3 work (provenance, hardened builds, advanced detection)
- Quarter 4 — Tier 3 deployed; first SOC 2 / ISO 27001 audit
After one year, the team has Tier 3. The pipeline is mature. The org is ready for enterprise customers, regulated industries, and high-stakes contracts.
17. The Resource Allocation
The investment:
| Tier | Headcount (FTE) | Cost (annual) | Time to deploy |
|---|---|---|---|
| 0 → 1 | 0.5–1 FTE | 200k | 30 days |
| 1 → 2 | +0.5 FTE | 200k | +60 days |
| 2 → 3 | +1 FTE | 300k | +90 days |
| 3 → 4 (world class) | +0.5 FTE | 200k | +90 days |
Total Year 1 investment: 2–3 FTE, 700k. For a mid-size org (50 engineers), this is <2% of engineering budget. The ROI is many times over.
18. Reading List for the M01 Reader
If you are new to DevSecOps, the recommended reading order:
- This module — orientation
- M03 — the Secure SDLC frame
- M02 — threat modeling
- M04 — security requirements
- M18 — compliance evidence (the “why does this matter” perspective)
- M20 — the capstone
If you are experienced and want depth on a specific area, jump to the relevant module.
19. The Final Thought
DevSecOps is a discipline, not a project. You do not “complete” it. You practice it.
The 20 modules in this curriculum are the minimum viable knowledge for a DevSecOps practitioner. The mature practitioner reads further, practices more, and shares learnings. The team that practices together gets better together.
The first step is the hardest. After the first step, the path is clearer.
20. Common Objections (Extended)
| Objection | Why it’s wrong |
|---|---|
| ”We have a security team for that” | The team cannot scale to every PR; the work must be distributed |
| ”We use GitHub Advanced Security” | Tooling is not DevSecOps; you can have GHAS and still be reactive |
| ”We are too small” | Tier 1 controls are free and take 30 days to deploy |
| ”We are too regulated” | The pipeline satisfies regulations; manual processes do not |
| ”Engineers don’t want to do this” | Engineers want to ship; the pipeline makes shipping safer and faster |
| ”It’s too expensive” | The cost of one breach is 10–100× the cost of the pipeline |
| ”We tried and it failed” | The failure was a tooling or culture problem, not a concept problem |
| ”Our stack is different” | The 20 modules apply to every stack; the tools differ |
21. The 20-Module Curriculum Map
The curriculum is organized in 5 stages × 4 modules = 20. Each stage has a coherent theme:
| Stage | Theme | Modules |
|---|---|---|
| 0 | Foundations | M01–M04 (mindset, threat model, SDLC, requirements) |
| 1 | Code | M05–M08 (SAST, secrets, SCA, SBOM) |
| 2 | Build | M09–M11 (images, IaC, pipeline) |
| 3 | Deploy | M12–M15 (OIDC, signing, SLSA, policy) |
| 4 | Runtime | M16–M20 (secrets, detection, compliance, IR, capstone) |
The order is deliberate: foundation before tooling, tooling before gates, gates before runtime. The capstone (M20) integrates all of it.