What is DevSecOps?
Summary: DevSecOps rests on three pillars — security at every stage, automated, and shared by the whole team. This lesson gives a rigorous definition, explains shift left, presents the founding principles of defense in depth and zero trust, and traces the history of the discipline.
1. The three-pillar definition
Pillar 2 deserves to be understood in its deeper logic. Any manual check will be bypassed the day the pressure gets high — that is a sociological certainty, not a moral failing. An automatic check in the pipeline, on the other hand, cannot be persuaded by a commercial deadline.
Pillar 3 is the hardest, because it requires a change of culture, not just of tooling. Many organizations install DevSecOps tools while keeping a security team that plays the role of final gatekeeper. They then get the costs without the benefits.
2. Shift left illustrated
A clarification that avoids a frequent misunderstanding: shift left does not mean abandoning security in production. Stage B5 remains essential — runtime monitoring detects what no static analysis can see. Shift left means adding security early, not moving all security to the beginning.
Stage B1 is the most cost-effective of all, and the most neglected. A few hours of threat modeling at design time save months of fixes. The question to ask is simple: "what data do we handle, who would want to obtain it, and through which path might they try?".
3. The founding principles
Principle 3 is the one that has changed recent architectures the most. The old model, known as the castle model, considered the internal network safe: once past the firewall, everything was accessible. Incidents have shown this is untenable — an attacker who compromises a single component then moves around freely. Zero trust requires that every call be authenticated, including between two internal services.
Principle 5 is the most economical, and it is often forgotten in technical discussions. Removing an unnecessary dependency is a permanent and free security gain: it is an entire class of future vulnerabilities that will never concern you.
4. A brief history of DevSecOps
What to read into this timeline: the discipline has progressed through incidents, not through theory. Each major step corresponds to a catastrophe that demonstrated a structural weakness. Equifax imposed patch management, SolarWinds build chain security, Log4Shell component inventories.
The Equifax case remains the most instructive because it is the most mundane: the vulnerability was known, the fix had existed for two months, and no one had applied it. It was not a problem of technical skill, but of process.
5. What DevSecOps is not
Misunderstanding 4 deserves particular attention in a professional context. Compliance (ISO 27001, SOC 2, PCI-DSS, etc.) verifies that processes exist, not that they are effective. An organization can tick every box and remain massively vulnerable. Compliance is a useful regulatory floor, not a measure of actual security.
Misunderstanding 3 is the number one cause of failure of DevSecOps initiatives. A team that turns on every control at maximum gets a pipeline that fails constantly, and the first decision made under pressure will be to disable everything. Three controls that are respected are better than thirty that are bypassed.
6. The role of the security champion
This is the organizational model that works best in practice, and it is far more effective than hiring more experts. A champion from within the team knows the context, takes part in decisions as they are being made, and enjoys a legitimacy an external auditor will never have.
7. The comparison table
| Criterion | Classic security | DevSecOps |
|---|---|---|
| When | Before going to production | At every stage |
| Responsible | Separate security team | The whole team |
| Mode | Manual audit | Automated |
| Frequency | One-off (annual) | Continuous |
| Posture | Gatekeeper (blocks) | Guardrail (prevents) |
| Feedback to the developer | Report, weeks later | Immediate, in the editor |
| Compatible with continuous delivery | No | Yes |
| Dependencies | One-off snapshot | Permanent monitoring |
Remember in 30 seconds
- DevSecOps = three pillars: security at every stage, automated, shared by the whole team.
- The most important change is organizational, not technical.
- Whatever is manual will be bypassed under pressure. Automate.
- Shift left = adding security early, not removing security in production.
- Threat modeling at design time is the most cost-effective step, and the most neglected.
- Six principles: least privilege, defense in depth, zero trust, secure by default, minimize the attack surface, assume breach.
- Removing an unnecessary dependency is a permanent, free security gain.
- The discipline has progressed through incidents: Heartbleed, Equifax, SolarWinds, Log4Shell, xz.
- Equifax: the flaw was known, the fix had existed for two months. A process problem, not a skill problem.
- Compliance is not security — it is a floor, not a goal.
- Block on critical, report the rest. A pipeline that always fails will be disabled.
- The team security champion is the most effective organizational model.
Next: Real-world vulnerabilities: OWASP Top 10, CVE and CVSS →