Every launch crew runs a checklist before ignition, not after the rocket is already climbing. Instruments are tested where they sit, by the crew that will fly them, against failures they could plausibly meet. Software delivery looks surprisingly similar in teams that practise DevSecOps: the checks ride along with each change, so nothing leaves the pad unverified. This piece keeps the vocabulary ordinary while covering what the term includes, what it deliberately excludes, and the small set of rules that hold the whole thing together.
What DevSecOps means, and why nobody owns the word
DevSecOps is the practice of building security into the delivery pipeline and the teams that operate it, so each change arrives checked, traceable, and fit to ship — without a separate security stage tacked on at the end. The emphasis sits on placement. Instead of finished software going away for a review that returns forty findings three weeks later, the relevant checks run where the code already flows.
The term has weight behind it. NIST SP 800-204C describes it as a facilitating paradigm for CI/CD, SP 800-218 (the Secure Software Development Framework) assumes the same posture, and both US Department of Defence guidance and several OWASP projects use the vocabulary freely. Even so, no single normative definition exists anywhere. You will also run into “SecDevOps” and “DevOpsSec” — the reordered versions carry no distinct meaning, and arguing about them buys nothing. For a fuller treatment, the Ops Atlas entry on DevSecOps is the reference this piece draws on.
Three sentences capture the working posture. Checks move to where changes already flow, rather than waiting at a stage gate. Findings become owned work items with deadlines instead of entries in a report nobody reopens. And the evidence about each build — what went in, what was tested, who signed it — becomes an artefact in its own right, stored and queryable. Teams doing those three things practise the discipline whether or not they use the label; teams skipping them do not, whatever their slide decks announce.
DevSecOps controls with an address, not a shelf
The mental model that makes this manageable treats every control as an object with four properties: where it sits, how much it can be trusted, what it costs, and what it does when it trips — block, warn, or simply record. A pre-commit secret scanner and a quarterly penetration test are both security controls, but they occupy different positions, carry different confidence, and behave differently on failure. Naming those properties out loud ends most arguments, because two people can finally see they were describing different controls.
Those controls sort into seven families that map cleanly onto the SSDF practices: design and threat modelling (PW.1), dependency and supply-chain checks (PW.4), secret handling (PW.7), build and pipeline verification (PW.8), release gates (PS.1 through PS.3), and the evidence trail that auditors eventually ask for (PO.5). You do not need the mapping memorised; you need to know that when you place a control, it belongs to a family, and the family tells you what evidence it produces.
The four properties earn their keep in daily arguments. Position decides whether a control ever sees the change — a check that runs nightly misses everything merged between runs. Confidence separates rules trusted to block from ones that merely inform. Cost is honest bookkeeping: a dynamic test that takes an hour changes how often you can afford it. Action is the output, and picking it on purpose keeps the build green without leaving anyone blind.
What lives inside the pipeline — and what stays out
Scope discipline keeps programmes honest. The following belong squarely inside:
- Change-level threat modelling — short, structured sessions that ask how a new feature could be abused, run in under an hour rather than a fortnight.
- Automated scanning of the artefacts you actually ship — source analysis, dependency checks, infrastructure definitions, container images, and dynamic tests against running builds.
- Secret hygiene — catching credentials before they land, blocking them server-side, and rotating anything that slips through.
- Provenance work — software bills of materials, signatures, and build attestations that let anyone later ask “what exactly is running, and who built it?”
- Hardening of the pipeline itself — because the machinery that builds software has become a target in its own right.
- Gates, exceptions, and the people process around them — including who may waive what, and for how long.
Just as useful is the negative space. Runtime detection and response belongs to security operations. Estate-wide vulnerability prioritisation is its own discipline. Cluster-level controls, cloud posture management, and formal audit programmes each have their own houses. Pulling all of those under one banner is how initiatives stall. The prerequisite is modest but real: the team needs working DevOps basics first, because you cannot secure a pipeline that does not yet exist. Readers wanting the operations side will find a plain walk-through of AIOps and modern IT operations useful company for this piece.
How a DevSecOps gate earns the right to block
The single most quoted rule in the field answers a question every team eventually faces: when may a check refuse a merge? The workable answer has three conditions. The finding must be new, not inherited debt from before the check existed. It must be severe enough to matter. And the checker must be confident — meaning the finding is fixable and unlikely to be a false alarm. Everything else becomes tracked work with an owner and an expiry date, ninety days being a common ceiling. Baseline debt never blocks, because a gate that blocks on the past teaches people to bypass the gate.
The conditions for trusting automated source analysis follow the same logic, drawn from Google’s experience scaling such systems: only block when a rule’s effective false-positive rate is essentially zero; keep the volume of comments reviewers must read under ten percent; report results on changed lines rather than the whole repository; sample thirty findings per rule before trusting it; and treat an override rate above five percent a month as a signal the rule needs retirement, not enforcement.
Why the ground shifted
Nothing here is new-age thinking; the practice accumulated through a visible sequence of milestones. Rugged Software made the argument for developer-owned security back in 2010. A Gartner report used “DevOpsSec” in 2012. Then regulation arrived: the EU Cyber Resilience Act entered into force in December 2024, with its main obligations landing December 2027 — currently the only legally binding item in the pile. Meanwhile the US Office of Management and Budget rescinded its M-22-18 federal attestation memo in January 2026, and CISA joined seventeen organisations to revise the SBOM minimum elements in July 2026. Standards moved too: SLSA reached v1.0 in April 2023 and v1.2 later added a Source track, while OWASP’s Top 10:2025 widened category A03 to cover all supply-chain failures.
You do not need those citations at your fingertips. You need the direction of travel: buyers and regulators increasingly ask for evidence that ships with the software, and evidence is produced by pipelines, not by annual reviews. A team that can answer “what changed, who approved it, what was scanned, what is in the dependency tree” on demand is already most of the way there. The skills behind that answer overlap heavily with reliability work — practical site reliability engineering training covers the same muscle of instrumenting and verifying systems as they run.
Where to actually begin
Programmes that last start small and measure. A workable first week looks like this:
- Write the gate policy before buying anything: which findings block, which become tickets, who owns each decision.
- Turn on secret scanning in pre-commit hooks and server-side push protection — cheap, high yield.
- Emit an SBOM and a provenance attestation from the build, even if nobody consumes them yet.
- Store scanner output in a standard format (SARIF) so trends become visible.
- Rehearse one compromise scenario, such as a poisoned build action, before it happens for real.
Tooling supports each step — Gitleaks for credentials, CodeQL or Semgrep for source, Trivy for images and third-party libraries, Syft for inventories, ZAP for the dynamic side, Sigstore’s cosign for signing, and the OpenSSF Scorecard for a starting self-grade. Choose from that shortlist rather than a procurement catalogue, and remember the field’s honest admission: none of these standards or tools certifies anyone in DevSecOps. The evidence your pipeline produces is the only certificate on offer.
One caution closes this out. A stored SBOM is a claim, not a truth — a compromised build machine can attest falsehoods, so verification happens at deployment, not at signing time. And the human side matters as much as the tooling: teams that give champions ten to twenty percent protected time fold security into daily work, while teams that bolt it on see it quietly abandoned within a quarter. The pattern generalises across operations disciplines; the comprehensive operations handbook from xOps School makes a good next stop.