Why DevSecOps? - Drivers, Failure Modes, and the Models the Exam Tests
What this domain covers
The Why DevSecOps? domain tests whether you can justify the change, not just describe it. Questions probe the failure modes of traditional security, the business and technical drivers behind DevSecOps, and the models the exam uses to describe flow, feedback and learning. Expect definitions, driver-to-benefit matching, and scenarios asking what a team should have done differently.
Failure modes of the traditional model
- Security review arrives after the code is written, so findings land as a report weeks later, detached from the change that caused them.
- Dev is measured on speed, Ops on stability, Security on findings closed. The incentives point in different directions.
- Manual gates become queues; teams route around them with standing exceptions, disabled scanners and shadow pipelines.
- Remediation cost and blast radius both grow the later a defect is found, and production findings compete with feature work.
The DevSecOps answer
- Culture, Automation, Lean, Measurement, Sharing (CALMS), applied with security present in every phase rather than appended to the end.
- The Three Ways: flow of work left to right, fast feedback right to left, and continual learning through experimentation and blameless review.
- Shift left for design and code; shift right for runtime detection, response and learning. Both, not one.
- Security as code: versioned, automated controls such as policy-as-code, scanning, signed artifacts and SBOMs, which scale where human review cannot.
- The security team moves from gatekeeper to enabler: standards, tooling, threat-modeling help and targeted assurance.
- Guardrails over gates: fast, default-safe paths that make the secure option the easiest option.
Worked example
A team ships weekly but runs a single penetration test before each release. The last one produced 40 findings and a three-week delay. Reasoning: the control is lagging and lumpy, so risk is discovered at the most expensive moment and the schedule absorbs the cost. The redesign keeps the pen test for assurance but adds threat modeling at design, SAST, SCA and secret scanning on every pull request with feedback under ten minutes, DAST in staging, and an SBOM per release. Findings now surface where they are cheap, and the pen test targets business logic and authorization flaws that automation misses.
Traps that cost marks
- Describing DevSecOps as a tool purchase or a renamed team.
- Claiming shift left replaces pen testing or production monitoring.
- Rebuilding the same gate with a faster ticket queue.
- Confusing CALMS with the Three Ways.
- Treating security as one team's job rather than shared ownership.