Read the receipts from the past thirty months and a pattern emerges that no vendor deck captures: the discipline of DevSecOps has been pulled forward by regulation, yanked sideways by incidents, and quietly re-engineered by the teams that took it seriously early. This piece reads that record the way a state-of-the-market report should — dates, documents, and behaviour changes — and closes with what remains unsettled. The short version: 2026 finds the practice mature enough to be legible, uneven enough to be interesting, and still officially undefined.
The regulatory ledger: one binding law, one withdrawal
Two regulatory events define the current picture, and they point in instructively different directions. The first is the EU Cyber Resilience Act, which entered into force in December 2024 and applies its main obligations from December 2027 — the single legally binding item in the entire DevSecOps canon so far. Products with digital elements sold into the EU market will need demonstrated security handling through development and support, which converts the practice from good intention into market access. The second event ran the other way: in January 2026 the US Office of Management and Budget pulled its M-22-18 memo, which had required secure-software attestations from federal suppliers. One jurisdiction tightened while another loosened — evidence that mandates follow politics, while the underlying engineering practice has to survive both.
The lesson worth carrying into planning: an organisation that adopted these controls only to satisfy a specific memo now owns an orphaned programme, while one that adopted them because leaked pipeline credentials and poisoned dependencies were costing real money keeps its programme regardless of which way a capital moves. Procurement language is already adapting on the buying side, too — the defence fundamentals cited above read less like guidance and more like a contract exhibit, and suppliers who cannot produce build evidence are discovering the question arrives during due diligence, not after launch. The Atlas entry that anchors this analysis — the DevSecOps reference at xOps School — puts it plainly: the practice predates the paperwork and will outlast it.
Standards momentum, measured in revisions
The documentary scaffolding thickened on schedule through the period. The secure-development framework NIST publishes was issued at v1.1 in February 2022, mapped to the US executive order of that season, and a v1.2 draft has circulated since December 2025. The microservices-focused SP 800-204C arrived March 2022, describing the whole approach as a facilitating paradigm for CI/CD; its companion on refactoring, SP 800-204D, followed in February 2024. The US Department of Defence issued Enterprise DevSecOps Fundamentals v2.5 in October 2024 — a telling document, since defence buyers now specify the practice contractually. SLSA, the build-integrity ladder, published version 1.0 in April 2023; its 1.2 revision added a track grading the platforms that host code, not just the systems that build it. OWASP’s Top 10:2025 widened its third entry to supply-chain failures as a class. Around these sit the machine-readable formats doing unglamorous work: CycloneDX 1.7 (now an ECMA standard), SPDX 3.0, SARIF 2.1.0 for scanner findings, plus ASVS 5.0.0, SAMM v2 and BSIMM16 for organisations that measure maturity. The SBOM minimum elements gained a CISA-coordinated revision in July 2026, agreed with seventeen organisations.
The incident calendar as a teacher
Nothing moved practice faster than three public failures, and each taught a different half-lesson. March 2024 brought the XZ Utils backdoor, CVE-2024-3094, caught — unusually — before most deployments absorbed it, with federal advice amounting to “step back to 5.4.6”. Its enduring lesson concerns response speed: teams holding component inventories answered “are we exposed?” in minutes, and the inventory’s value was measured in that speed, not in any power to prevent the attack. March 2025 delivered the tj-actions/changed-files compromise, where a widely used build action turned hostile and runner secrets leaked downstream; the prescribed response was credential rotation, because the defect lived in delivery machinery, not in any application. March 2026, evidently a difficult month for trust, saw Trivy-related scan actions compromised through force-pushed tags serving a tampered release — contained the same evening, and memorable for what it falsified: the “Immutable” badge, which did nothing to prevent tag history being rewritten. Cryptographic pinning outlived every label the platforms display. Line the three incidents up and the composite lesson reads: assume the machinery can be turned against you, keep credentials short-lived so exposure windows stay small, hold inventories so exposure can be measured quickly, and verify what you deploy rather than trusting what was signed. Every one of those behaviours was cheap to adopt before the incidents and expensive to improvise after them — which is, in one sentence, the business case for the whole discipline.
What mature DevSecOps adopters actually changed
Against that backdrop, the behaviours separating mature programmes from banner purchases are now legible enough to list:
- They gate narrowly. Merges stop only for findings that are fresh, severe, and produced by reliable detectors; the rest becomes owned, dated work, and inherited debt never seals the merge path.
- They measure the gate like any production system: override rate against a five-percent monthly ceiling, false-positive rates per rule, fix times in median and tail, escapes traced to the check that missed them.
- They verify evidence at deployment rather than archiving signatures at build time — the single behaviour that survived every 2025–2026 incident post-mortem.
- They rehearse. A compromise runbook that has never been walked fails precisely when needed; the teams that practise recover in evenings rather than weeks.
- They staff it internally: champions holding protected time amounting to 10–20 percent of their week, inside delivery teams, with specialists reachable rather than intermediary.
The research record supports the staffing point beyond anecdote. The 2022 DORA analysis found burnout odds multiplied by 1.4 wherever security practice lagged, with culture — not spending — predicting adoption; two findings that keep reshaping how programmes are budgeted and whom they hire.
The metrics discipline is what makes these behaviours checkable rather than aspirational. One published worked example shows the arithmetic: a month of 1,240 pull requests produced 96 blocks, of which 22 were overridden — 22.9 percent, which the reviewers called fatal to the gate’s credibility, since engineers calibrate to any block they have watched collapse. The same exercise demoted one rule on a 43.6 percent effective false-positive reading, recorded 398 of 412 deploys carrying verifiable provenance, and traced nine production escapes to find three that a muted check would have caught. Five numbers, one afternoon of querying, and a programme knows whether it is improving or cosplaying.
What DevSecOps still has not settled
Honesty requires the short list of things the discipline cannot yet answer. No normative definition exists; the term — alongside its SecDevOps and DevOpsSec spellings — carries no agreed word-order meaning, and NIST documents describe posture rather than prescribe a canon. No certification exists — no exam to sit, no badge to display, no audit stamp to frame, whatever course brochures imply. The job title has no standard scope, which is why two adverts of the same name describe different jobs. And the scope boundary itself stays contested at the edges — runtime response, estate-wide vulnerability ranking, cluster controls, cloud posture and audit programmes each belong to neighbouring disciplines, and programmes claiming all of them tend to finish none. For teams planning the coming year, that unsettledness argues for the boring approach: pick the narrow, evidenced version of the practice, document the choice in one page, and let the arguments continue without you.
Carrying the practice into delivery work starts with the foundations this site covers elsewhere: the quick tutorial on understanding pipelines, the measured take on what certifications are actually worth — a relevant question in a field that issues none — and the transformation-level view in DevOps for IT transformation. The discipline’s history is young enough that reading its receipts — the dates above, the incidents, the withdrawals — is still the fastest way to predict where it goes next.
