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 \u2014 dates, documents, and behaviour changes \u2014 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.<\/p>\n
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 \u2014 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 \u2014 evidence that mandates follow politics, while the underlying engineering practice has to survive both.<\/p>\n
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 \u2014 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 \u2014 the DevSecOps reference at xOps School<\/a> \u2014 puts it plainly: the practice predates the paperwork and will outlast it.<\/p>\n 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 \u2014 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.<\/p>\n 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 \u2014 unusually \u2014 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 \u2014 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 \u2014 which is, in one sentence, the business case for the whole discipline.<\/p>\n Against that backdrop, the behaviours separating mature programmes from banner purchases are now legible enough to list:<\/p>\n 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 \u2014 not spending \u2014 predicting adoption; two findings that keep reshaping how programmes are budgeted and whom they hire.<\/p>\n 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 \u2014 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.<\/p>\n Honesty requires the short list of things the discipline cannot yet answer. No normative definition exists; the term \u2014 alongside its SecDevOps and DevOpsSec spellings \u2014 carries no agreed word-order meaning, and NIST documents describe posture rather than prescribe a canon. No certification exists \u2014 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 \u2014 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.<\/p>\n Carrying the practice into delivery work starts with the foundations this site covers elsewhere: the quick tutorial on understanding pipelines<\/a>, the measured take on what certifications are actually worth<\/a> \u2014 a relevant question in a field that issues none \u2014 and the transformation-level view in DevOps for IT transformation<\/a>. The discipline’s history is young enough that reading its receipts \u2014 the dates above, the incidents, the withdrawals \u2014 is still the fastest way to predict where it goes next.<\/p>\n","protected":false},"excerpt":{"rendered":" A state-of-the-field read on DevSecOps in 2026: regulation swings, standards momentum, three years of pipeline incidents, and what mature adopters changed.<\/p>\n","protected":false},"author":5,"featured_media":1816,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[490],"tags":[],"class_list":["post-1815","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devsecops"],"_links":{"self":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1815","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/comments?post=1815"}],"version-history":[{"count":1,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1815\/revisions"}],"predecessor-version":[{"id":1825,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1815\/revisions\/1825"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media\/1816"}],"wp:attachment":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media?parent=1815"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/categories?post=1815"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/tags?post=1815"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Standards momentum, measured in revisions<\/h2>\n
The incident calendar as a teacher<\/h2>\n
What mature DevSecOps adopters actually changed<\/h2>\n
\n
What DevSecOps still has not settled<\/h2>\n