What is DevSecOps?
DevSecOps is not a new team or a new tool category bolted onto DevOps — it's DevOps' own culture and automation applied to security specifically. By the end of this page you should be able to state precisely what changes when a team goes from "security reviews before release" to "security is everyone's continuous job," and name the four ideas — CALMS, shift-left, Rugged DevOps, and security as code — that make that change concrete instead of aspirational.
A spell-checker that runs while you type catches a typo the second you make it, when fixing it means pressing one key. A copy editor who only reads the finished manuscript the night before it ships also catches typos — but now fixing one might mean reprinting a page, and there's no time left to be thorough, so things slip through. DevSecOps is choosing to run the spell-checker continuously, everywhere in the writing process, instead of hiring one very tired editor for the last night.
DevOps' CALMS, with security as a first-class thread
DevOps is often summarized with the acronym CALMS — Culture, Automation, Lean, Measurement, Sharing — a framing credited to John Willis and Damon Edwards (originally CAMS), with Lean added later by Jez Humble. DevSecOps doesn't replace this framework; it runs security through all five of its levers instead of leaving security outside them:
- Culture — security is a shared value the whole team owns, not one team's separate turf.
- Automation — checks run in the pipeline on every commit, not in a scheduled review meeting.
- Lean — small, fast feedback loops replace one giant end-of-cycle audit.
- Measurement — vulnerability density, mean-time-to-remediate, and scan coverage get tracked sprint over sprint, the same way a team already tracks deploy frequency and lead time.
- Sharing — developers, security engineers, and operations look at the same dashboards and the same backlog, not three separate ones.
Put plainly: DevSecOps is the practice of making security a continuous, automated, and shared responsibility across the whole software delivery lifecycle, instead of a distinct phase a separate team owns near the end. The rest of this page is about what that replaces and what it takes to actually run it.
The traditional model: security as a late-stage gate
Before DevSecOps, most organizations ran security as a single checkpoint: a dedicated security or application-security team reviewed a feature after development finished and just before release. The relationship was structurally adversarial — the dev team handed over something they considered done, and the security team's job was to find reasons it wasn't. A finding meant a ticket back to engineers who had usually already moved on to the next piece of work, so re-establishing context cost as much as the fix itself. Multiply that across every release and the review queue becomes the bottleneck: a single manual gate that every change has to pass through, staffed by a team that's necessarily smaller than the whole engineering org it's reviewing.
This model optimizes for having one auditable checkpoint, not for fast or cheap feedback. It also trains the wrong instinct: when security only shows up at the end to say no, developers learn to see them as a blocker to route around rather than a partner in getting the design right, and security teams learn to distrust code they had no visibility into until it was "finished." See the secure SDLC for how this sequencing played out across a full release cycle, and what replaces it.
Shift-left: moving activities earlier, not moving them only there
Shift-left means moving security activities as early into the SDLC as possible, because that's where a fix is cheapest. The commonly cited rule of thumb — a defect caught during design costs roughly 1x to fix, the same defect caught in code review costs several times that, and the same defect caught in production costs an order of magnitude more again — traces back to studies (the IBM Systems Sciences Institute figure gets quoted constantly and rarely sourced) that don't hold up to close scrutiny on the exact multipliers. The direction, though, isn't in dispute: the further a defect travels before someone finds it, the more code, deployment, and investigation surround it by the time it's fixed.
In practice, shifting left means threat modeling during design instead of after the fact, static analysis (SAST) running at code review instead of at release, and dependency and infrastructure-as-code scanning happening at build time rather than being discovered in production.
That last node in the diagram is the point this section keeps coming back to: shift-left is an "also," not an "only." Design-time and code-time checks catch a large share of preventable issues far more cheaply than production ever could, but they can't see everything a running system will encounter.
"Shift-left" gets misread as "security only happens at the start." It doesn't. Threat modeling and SAST can't see a misconfigured resource created by a runtime change, a credential leaked into a log stream, or a fresh exploit against a dependency that was clean when it shipped. A pipeline that shifts checks left and then stops watching in production has just traded one blind spot for another — see incident response and forensics for what has to keep running after release.
Rugged DevOps: engineering for hostile conditions, not just correctness
In 2010, Josh Corman and a group of collaborators from the application-security community introduced the idea of Rugged software and the Rugged Manifesto — a response to an industry that tested software for whether it worked, but rarely for whether it would keep working under deliberate, hostile pressure. "Rugged" borrows from engineering disciplines outside software: a rugged laptop is designed for drops, dust, and temperature extremes, not just for running its intended programs correctly on a desk. Rugged software applies the same standard to code — it should be built to withstand hostile conditions (attackers, misuse, scale, and time), not merely to pass a functional test suite.
Rugged DevOps is what happens when that mindset meets DevOps' operational machinery. The manifesto supplies the "why" — attackers are an environmental condition to engineer for, the same way load and latency already are — and DevSecOps supplies the "how": the automated checks, shared metrics, and pipeline gates that make ruggedness something a team actually practices on every commit instead of something they merely believe in. That shift — from a value a team holds to a habit a team's tooling enforces — is also why security culture and champions matters as much as any scanner: rugged is ultimately a property of how a team thinks about its own code.
Security as code: automated, versioned, pipeline-enforced
Security as code means expressing security requirements as rules that live in version control and run automatically, rather than as a checklist a person walks through by hand. The rules are code: reviewable in a pull request, testable, and diffable, exactly like the application code they govern. Concretely, that looks like:
- An Open Policy Agent (OPA) policy written in Rego, enforced through a Kubernetes admission controller or a CI check against a Terraform plan — see IaC security and policy as code.
- Checkov or tfsec scanning infrastructure-as-code before
terraform applyis allowed to run. - A SAST or SCA tool wired in as a required, merge-blocking status check — see SAST, DAST & SCA and security in CI/CD.
- gitleaks or a comparable secrets scanner, running pre-commit and again in the pipeline, so a leaked credential doesn't reach a shared branch in the first place.
The difference from a manual review isn't just speed, though speed matters — a person reading a diff can review a handful of pull requests a day, while a policy check runs on every single commit, in seconds, identically every time. The bigger difference is consistency and auditability: the rule doesn't depend on which reviewer was paying attention, and a change to the rule itself is a tracked, reviewable diff instead of a change in one person's judgment.
Security as code turns a policy from something a reviewer remembers to enforce into something the pipeline literally cannot skip. That's the mechanism that makes shift-left durable — without it, "check earlier" is just a suggestion that erodes under deadline pressure the first time a release is late.
1. What do the five letters in CALMS stand for, and what's the DevSecOps twist on the framework? 2. Why did the traditional "security team reviews right before release" model tend to become a bottleneck? 3. What does "shift-left" mean precisely, and what's the common misreading of it that this page pushes back on? 4. Give one concrete example of "security as code" and explain what makes it different from a person reviewing a diff.
Check your answers
- Culture, Automation, Lean, Measurement, Sharing. DevSecOps runs security through all five — it becomes something the whole team shares, automates, measures, and iterates on quickly, rather than something a separate team owns and reviews at the end.
- Because it was a single, late, manual checkpoint staffed by a smaller team than the engineering org it reviewed: every finding sent work back to developers who had already moved on, turning security into a source of delay and an adversarial back-and-forth instead of a property built into the code from the start.
- Shift-left means moving security activities as early into the SDLC as possible, because a defect is cheapest to fix the moment it's introduced. It does not mean moving all security activity to the start and dropping everything after — some risks (misconfigurations from runtime changes, leaked credentials, new exploits against previously clean dependencies) are only visible once the system is live, which is why production monitoring still has a place on the timeline.
- For example, an Open Policy Agent rule that blocks a Terraform plan from being applied if it opens a security group to the whole internet. Unlike a manual review, it runs on every commit, in seconds, identically every time, and the rule itself is versioned and reviewable in git rather than depending on which reviewer happened to be paying attention that day.