Introduction to DevSecOps
This domain covers the definition and mechanics of DevSecOps: what actually changes when security is embedded in a delivery pipeline rather than bolted on at the end. Expect questions on shift-left economics, security as code, shared ownership, and the security team's changed role.
Core rules
- Shift left means moving security activities earlier and making them continuous - threat modelling in design, SAST on commit, SCA at build, DAST in staging, runtime protection in production. Early detection is cheaper because the defect has not propagated into design, data and interfaces.
- Security as code: policies, guardrails and compliance checks live in version control, are reviewed, and are executed by machines (OPA policies, IaC scanners, pipeline gates).
- Shared ownership: developers own secure implementation, operations owns hardened runtime, the security team owns standards, tooling, threat intelligence and enablement - it becomes an internal consultancy, not a tollbooth.
- Security champions are embedded developers with extra training who review code and translate policy into team practice.
- Maturity models such as OWASP SAMM and BSIMM give a structured way to measure and improve; they are governance frameworks, not scanners.
- Shift right complements shift left: some controls (WAF, anomaly detection, incident response) only make sense at runtime.
Worked example
A team ships a service with an injection flaw. Option A: annual penetration test catches it ten months later, after it is deployed, documented and depended on; remediation touches code, tests, documentation and possibly customer notification. Option B: a SAST rule and a peer-review checklist catch it in the pull request, before merge; remediation is minutes and the developer learns the pattern. The exam answer is B, and the reasoning must cite cost of change and blast radius, not just 'SAST is good'.
Traps that cost marks
- Treating shift left as a tool installation; without process change and triage ownership, scanners produce ignored noise.
- Concluding DevSecOps eliminates the security team - it re-scopes it.
- Assuming every control belongs at commit time; runtime controls still matter.
- Buying tooling before defining policy and acceptance thresholds.
- Ignoring that automated gates need an exception path, otherwise teams route around the pipeline.