Expert DevSecOps and specialisations: DSOMM and platform

This career stage is for engineers who have already practised DevSecOps in production and want to become an expert DevSecOps engineer: govern a platform, set standards, steer an organisation's maturity or specialise in a precise domain. You will learn to measure a transformation objectively with the DSOMM (DevSecOps Maturity Model) and the DORA metrics (the 5 reference indicators of software delivery performance), to build an Internal Developer Platform (IDP), to secure Kubernetes in depth and to apply policy as code. The page then presents 7 specialisations recognised by the job market, and ends by saying how to validate the stage with the notes-api common thread.

Estimated duration: 100 to 150 hours depending on the specialisation you choose.

What you will learn

Lead a DevSecOps maturity audit (DSOMM) and derive a prioritised roadmap from it
Design and run an Internal Developer Platform (IDP) for development teams
Configure and audit the security of a Kubernetes cluster (RBAC, Network Policies, admission controllers)
Implement policy as code with OPA/Gatekeeper or Kyverno
Define architecture standards and reusable patterns at the scale of an organisation
Choose and prepare for a specialisation among the 7 job profiles of this stage

Block 1: Organisational implementation

DevSecOps expertise is not only technical. It means understanding how to structure teams, measure progress and raise the collective level. The DSOMM (DevSecOps Maturity Model, a framework maintained by OWASP) is the foundation for objectively establishing where an organisation really stands. Team Topologies, whose second edition appeared in 2025 and puts cognitive load at the centre of the model, provides the vocabulary to organise teams around the value stream rather than around technical silos.

The DSOMM maturity audit gives the figures for the starting point, and the maturity roadmap turns it into a plan over 12 to 24 months. On the organisation side, Team Topologies presents the four team types and their interaction modes, and the guide on roles and Team Topologies places each DevSecOps role in that model. To raise the collective level, a network of Security Champions relays security into every team, and a training programme replaces the annual awareness day with continuous practice.

Block 2: KPIs, metrics and security monitoring

Without measurement, security remains a matter of opinion. This block covers how to steer progress objectively and demonstrate the value of DevSecOps. The DORA report (DevOps Research and Assessment, published every year by Google Cloud) was renamed in 2025 State of AI-assisted Software Development: it keeps the 4 historical metrics (deployment frequency, lead time, change failure rate, time to restore, already renamed Failed Deployment Recovery Time in 2023 so that it counts only incidents caused by a deployment) and added a fifth indicator in 2024, the Rework Rate, which measures the share of unplanned deployments meant to fix a defect. Knowing this evolution avoids steering with an outdated dashboard.

The security KPIs measure what the security team must steer: time to fix, false positive rate, vulnerability debt, coverage. The implementation of DORA metrics shows how to collect the five indicators without distorting team behaviour, and SLOs, SLIs and error budgets link reliability to deployment decisions.

Block 3: Platform Engineering

Platform Engineering is the structural answer to the problem of scaling DevSecOps. Rather than training every team on every tool, you build an internal platform (IDP, for Internal Developer Platform) that makes good practices easy by default. This movement has gone mainstream: Gartner forecast in 2022 that 80% of large software engineering organisations would have a dedicated platform team by 2026 (a forecast, not a measurement), and practice has shifted towards platform-as-product (treating the platform as a product with internal users to satisfy) rather than a mere infrastructure layer.

The Platform Engineering guide covers what an IDP is, tools such as Backstage and Crossplane, and the golden paths that make the good practice simpler than the bad one. The Dev-Sec collaboration lesson shows how to build security controls into this self-service without turning it back into a ticket desk.

Block 4: Kubernetes security

Kubernetes is the target infrastructure of most Cloud Native deployments, which makes it a priority target for an attacker. Securing it covers RBAC (Role-Based Access Control, which limits rights by role rather than by account), Network Policies (a firewall inside the cluster that filters pod-to-pod flows) and admission controllers, which validate or reject a resource before it is created. The CKS (Certified Kubernetes Security Specialist) certification curriculum was overhauled by the CNCF on 15 October 2024, aligned with Kubernetes 1.31, then updated with each version: the latest curriculum published in the CNCF repository is v1.34, dated 30 October 2025.

The Kubernetes security overview (in French) walks through a cluster's attack surface and the controls that reduce it. Container security goes one level down: minimal images, vulnerability scanning, runtime security. To understand what a container really isolates, cgroups and the other kernel primitives remain the reference.

Block 5: Infrastructure as Code and policy as code

Insecure IaC (Infrastructure as Code) is an entry point like any other: a badly written Terraform module can open public access as surely as a bad manual configuration. Policy as code means writing compliance and security rules as versioned, tested and automatically enforced code, with tools such as OPA/Gatekeeper or Kyverno for Kubernetes admission controllers. This block covers how to choose, structure and secure your IaC before industrialising it at the scale of an organisation.

The Infrastructure as Code section (in French) helps you choose between Terraform, Ansible and Pulumi, then structure and secure the infrastructure code. The principle to remember: a security rule that is not written as code ends up enforced only by those who remember it. On the Kubernetes side, the comparison VAP, Kyverno or Gatekeeper (in French) helps you choose the admission engine; on the Terraform side, the policy as code guide applies the same logic before deployment.

Block 6: Advanced pipeline and supply chain security

The software supply chain (all the dependencies, tools and steps that turn source code into a deployed artefact) has become a favourite target: compromising a single link can reach thousands of victims downstream, as several major incidents on npm or PyPI packages have shown in recent years. At this stage you go beyond basic vulnerability scanning to aim for the SLSA (Supply-chain Levels for Software Artifacts) Build L2 and L3 levels, the highest of the build track since version 1.0, systematic signing with Sigstore in production, and a tooled CVE management workflow: triage, SLAs, exceptions documented with VEX.

The supply chain security guide details the SLSA Build L2 and L3 levels, Sigstore in production, in-toto and the verification policy. Vulnerability management covers the triage and the exceptions, and the supply chain security overview puts Grype, Syft, Cosign and Rekor into practice.

Block 7: Identity, secrets and access

Workload identity (the cryptographic identity assigned to a service rather than to a human) has become the new frontier of application security. SPIFFE/SPIRE (Secure Production Identity Framework For Everyone, and its reference implementation SPIRE) is the open standard that distributes these identities automatically between workloads, with no shared password to manage. Zero trust (never trust by default, even inside the network) and advanced secrets management complete this block on modern trust architectures.

The secrets management course goes as far as advanced uses: automatic rotation and dynamic secrets, leased for a bounded time so that a secret expires by itself. It is the natural complement to workload identity: a service that proves its identity no longer needs a static secret.

Block 8: Advanced SRE

Site Reliability Engineering (SRE) applied at the expert stage goes beyond simply defining SLOs. It means treating error budgets as a decision tool shared with the product side rather than as an isolated technical constraint, running systemic postmortems that look for organisational causes rather than individual fault, and pushing observability beyond dashboards towards distributed tracing and continuous profiling, to tell a user-visible symptom from an internal technical cause.

The SRE guide is worth rereading at this stage with fresh eyes: the error budget becomes a shared decision tool, and the postmortem looks for systemic causes. The observability section (in French) covers distributed tracing, continuous profiling and symptom-based alerting.

Which specialisations after the expert stage?

At this stage you can move towards one of the 7 specialisations. Each one matches a real job profile on the market, with its own key skills and, depending on the case, its reference certifications and the career moves it opens.

Focus: build security into the whole SDLC, from design to production monitoring.

Key skills: threat modeling, automated security testing, secure pipeline, supply chain, secrets management, Kubernetes security, leading Security Champions.

Recommended certifications:

Certified DevSecOps Professional (Practical DevSecOps)
CKS (Certified Kubernetes Security Specialist)

Career moves: towards security architecture (Security Architect), offensive security (pentest, Red Team), governance (chief information security officer) or product (Security Product Manager).

The DevSecOps Engineer career path details its responsibilities, missions and the skills expected, course by course.

How do you validate the expert stage?

No exam closes this stage. The only automated check is the notes-api common thread, the course capstone: it hardens a single service across versions V0 to V11 (plus an annex version, V9b), and each version is judged by checks on the state of the result. It covers only part of this page, and each lesson of the course carries its own quiz to check the concepts along the way.

The table says which versions of the common thread match which blocks of this stage, and in which track of the course they are played: Essential or Complete.

Block of this page	Common thread version	Track
Block 2, KPIs and metrics	V11: SLO, runbook, DORA metrics	Essential
Block 6, supply chain	V10: dated exceptions and VEX; V7: SBOM and provenance	Essential; Complete
Block 4, Kubernetes security	V9: restricted Pod and NetworkPolicies; V9b: Falco rules	Complete
Block 5, policy as code	V8: Kyverno admission policies	Complete
Block 7, identity and access	V4: OIDC with no stored key	Complete

On the Essential track, the common thread comes down to seven versions (V0 to V3, V6, V10, V11) and does not require Kubernetes: so for this stage it checks only V10 and V11. The other rows of the table require the Complete track and its lessons; V8 and V9 also need a kind cluster, and V9b a virtual machine.

No version checks Kubernetes RBAC, secrets management with Vault, a DSOMM audit and its roadmap, a multi-environment pipeline or an internal platform. These skills are proven on your own project, for example a quantified maturity audit followed by a prioritised action plan, or a cluster whose permissions have been reviewed and documented.

Key points

The DevSecOps expert does not do everything personally: they create the conditions for teams to do it well.
Maturity is measured, steered and demonstrated with concrete data, not with impressions.
The DSOMM and the DORA metrics (completed in 2024 by a fifth indicator, the Rework Rate) give a common language to steer a transformation without injecting personal opinions into it.
Platform Engineering does not replace security: well designed, it builds security into the path of least resistance for developers.
Kubernetes security (RBAC, Network Policies, admission controllers) and policy as code are now expected skills, not options.
The 7 specialisations of this stage match real job profiles on the market, each with its own scope and key skills.
No certification replaces production experience: it validates a base of knowledge, not the incidents actually lived through.
Specialisation always starts from a mastery of the Getting started and Operational DevSecOps stages: experts who skipped stages have blind spots they cannot see.