Module 09 of 12
The DevSecOps Mindset
Security isn't a gate at the end of the pipeline. It's everyone's job, applied everywhere along the way — not just "shift left," but shift everywhere.
If you've followed this course from Module 1, DevSecOps should feel less like a new topic and more like a direct application of everything you already know. DevOps removed the wall between building and running software. DevSecOps removes a second wall: the one between building software and securing it — the traditional model where a separate security team reviews (or blocks) a release right before it ships, armed with a checklist and very little context about why the system was built the way it was.
That traditional model has the exact same structural flaw as the pre-DevOps wall between Dev and Ops: the people who understand the system best (the developers) have the least visibility into its security posture, and the people who understand security best (a separate security team) get involved so late that fixing what they find is expensive, disruptive, and often gets waved through under deadline pressure instead of actually fixed. DevSecOps' answer is the same as DevOps' answer: stop treating security as someone else's downstream problem, and build the feedback loop directly into how software gets made.
"Shift left": the same idea as Module 4, applied to security
You already learned the general principle in the Feedback Loops module: the earlier a problem is caught, the cheaper it is to fix, because less has been built on top of the mistaken assumption and less context has been lost. "Shift left" is that exact principle, named specifically for security: move security checks left on the timeline — into design, into the IDE, into code review, into CI — instead of leaving them all clustered at the right edge, in a pre-release security review or, worse, in production after an attacker finds them first.
The economics back this up starkly: industry estimates commonly cited in security literature put the cost of fixing a flaw found at the design stage around $80, versus roughly $7,600 for the same category of flaw found after the software is already deployed — a difference of two orders of magnitude, for what is often the exact same underlying mistake. That gap is the entire argument for shifting left, made concrete.
2025's refinement: "shift everywhere"
"Shift left" is the right first instinct, but taken too literally it can become its own anti-pattern: cramming every possible security check into the design and coding stage, making the developer inner loop so slow and noisy that people start ignoring it — the same feedback-loop degradation from Module 4, where a slow, over-loaded loop stops being useful. The industry's more mature framing as of 2025 is "shift everywhere": distribute proportionate security checks across the entire lifecycle instead of front-loading all of it. Lightweight, fast checks live in the IDE and pull request (so they don't slow anyone down); more thorough, slower checks live in the CI/CD pipeline as a gate before deploy; and runtime monitoring watches production continuously, because no amount of pre-deployment checking catches everything — some things are only observable once the system is actually running under real conditions.
Shift left is about timing (catch it earlier). Shift everywhere is about distribution (catch it continuously, at the right depth, at every stage) — a fast, shallow check in the editor, a slower, deeper gate in CI, and permanent watchfulness at runtime.
Case study: Equifax, 2017
Case Study
Equifax Data Breach — 2017
In March 2017, the Apache Software Foundation disclosed a critical vulnerability (CVE-2017-5638) in Apache Struts, a web framework Equifax used, and released a patch the same day. Equifax did not apply it. Attackers exploited the same known, already-patched flaw starting in mid-May 2017, and over roughly two months, stole the personal data of nearly 148 million people — Social Security numbers, birth dates, addresses, driver's license numbers. The breach wasn't discovered until July 29, 2017. This wasn't a novel, undiscoverable attack. It was, in the words of multiple post-incident analyses, "a crisis of fundamentals": a known vulnerability, with a known fix, publicly available for roughly two months before attackers used it — and an expired internal security certificate that should have helped detect the exfiltration sooner also went unnoticed.
Notice what this case study is not: it's not a story about a sophisticated zero-day exploit that no reasonable process could have caught. It's a story about a patch that existed, sitting unapplied, in a system that presumably had a security team, a patch management process, and a compliance function — all the trappings of "having security" in the old, walled-off sense. What was missing wasn't security expertise. It was the DevSecOps property this module is about: a fast, reliable, automated feedback loop connecting "a critical patch exists for something we run" to "that patch gets applied," at the speed attackers operate at, not the speed a quarterly review cycle operates at.
A DevSecOps-minded organization treats "do we have a critical unpatched dependency" the same way a DevOps-minded organization treats "is the site down": as something continuously and automatically monitored, that pages someone, rather than something discovered during a periodic manual review — the exact distinction between a fast organizational feedback loop and a slow, easily-missed one from Module 4.
Security as everyone's job — not nobody's job
"Security is everyone's job" is a phrase that can sound like corporate hand-waving, so it's worth being precise about what it actually changes in practice. It does not mean the security specialists disappear, any more than "you build it, you run it" from Module 5 meant operations expertise disappeared — deep security expertise (threat modeling complex systems, incident response, cryptography review) remains genuinely specialized work. What changes is where the baseline responsibility sits: a developer is expected to know and apply basic secure coding practices the same way they're expected to write basic tests, automated tools catch common classes of vulnerability before a human reviewer ever needs to, and the security team shifts from being the last-minute gatekeeper to being the people who build those automated guardrails and handle the genuinely hard, specialized cases.
This is the DevSecOps version of the DevOps ownership shift: responsibility moves from being concentrated in a separate department, checked at the very end, to being distributed and continuous — with the specialist team's role changing from gatekeeper to enabler.
Think it through
Real situations, no single "correct" checkbox — reason about it first, then compare your thinking to ours.
Scenario 1
A security team introduces a mandatory, full security review before every release, performed entirely by the security team, taking three to five business days. Developers, facing deadline pressure, start batching multiple features into fewer, larger releases to reduce how often they have to go through the review.
How does this policy interact with the ideas from Module 4 (feedback loops) and this module's "shift everywhere" principle?
Scenario 2
A company's automated dependency scanner flags a critical vulnerability in a library, similar in severity to the Equifax case, and automatically opens a ticket. The ticket sits unassigned in a backlog with hundreds of other tickets for six weeks before anyone notices it.
What is actually missing here — the detection tooling, or something else?
Check your understanding
Answer all questions, then submit to see explanations.
1. What structural problem does DevSecOps address, analogous to the original Dev/Ops wall?
2. Roughly how much cheaper is it to fix a flaw at the design stage versus after deployment, per commonly cited industry estimates?
3. What does "shift everywhere" add to the original "shift left" idea?
4. In the Equifax breach, what was the core failure?