Implementing DevSecOps: the complete path

What you will learn

This path guides you through the concrete implementation of DevSecOps. It is organised like a training book in 5 progressive parts, plus an appendix on careers.

Prerequisites: have read the DevOps Fundamentals (or at least parts 1 and 3).

Estimated duration: 2 to 3 hours of reading, several weeks of real implementation.

Where you are: this section mostly feeds the Expert career stage (organisation, maturity, metrics); its part 5 joins the Operational stage. The DevSecOps course draws a large share of it: team organisation, measurement, scaling up, vulnerability management and the common thread.

You have understood the DevSecOps theory: the Three Ways, the CALMS model, the DORA metrics. What remains is the question that blocks most teams: how do you move to practice without getting lost among tools, roles and priorities? This guide answers with a path structured in five parts, concrete examples and actionable tools, designed for a technical manager or lead who has to launch or relaunch a DevSecOps transformation.

Overview of the implementation path

The path follows a logical progression: assess where you stand, organise your teams, train your people, measure the results, then deliver continuously. Each part builds on the previous one: there is no point automating a pipeline (part 5) if nobody has been trained (part 3) or if you ignore your starting point (part 1).

Part	Goal	Reading time	Chapters
1, Assess	Establish your baseline	30 min	2 chapters
2, Organise	Structure your teams	45 min	4 chapters
3, Train	Develop skills	30 min	2 chapters
4, Measure	Steer with data	30 min	2 chapters
5, Deliver	Automate delivery	30 min	3 chapters
Appendix	Understand the roles	10 min	6 career path pages

Swipe to see more

---

Part 1, Assess

Goal: know where you are starting from in order to prioritise your actions.

Before launching a transformation, you must measure your current maturity. Without a baseline, it is impossible to demonstrate progress or to justify an investment to management. This part gives the tools to establish an objective diagnosis rather than a subjective impression. Why aim for higher maturity and how to choose the next steps is covered in Maturity and roadmap: here, we measure.

1. DSOMM maturity audit

   Assess your level on the 5 dimensions of the OWASP DSOMM model (DevSecOps Maturity Model, a maturity framework): Build & Deployment, Culture & Organization, Implementation, Information Gathering, Test & Verification. Identify your strengths and gaps dimension by dimension.

2. The 4 quality pillars

   Understand the 4 pillars of a quality system (Security, Reliability, Operability, Maintainability) and identify your concrete priorities.

---

Part 2, Organise

Goal: structure your teams to maximise the value stream.

The structure of your teams determines the quality of your software (Conway's law). This part teaches you to apply Team Topologies, the team organisation model formalised by Matthew Skelton and Manuel Pais, to map roles, to build an internal platform and to reduce friction between development and security. In 2026, this framework has become the de facto common reference for organising delivery teams: most technical org charts refer to it explicitly or converge on the same structures without knowing it.

1. Team Topologies

   The 4 team types and the 3 interaction modes. How to move from theory to practice, without a big-bang reorganisation.

2. Mapping roles x topologies

   Where to place the SRE, the Platform Engineer, the Security Champion depending on context and organisation size.

3. Platform Engineering

   Set up the platform team and its internal platform (IDP), treated as a product. The why of this platform is laid down in the Fundamentals Horizon.

4. Dev-Sec collaboration

   Install feedback loops and a blameless culture between teams.

---

Part 3, Train

Goal: develop security skills across the whole organisation.

Tools are not enough. Without a cultural transformation, you will have a technically perfect CI/CD and just as many silos between teams. This part teaches you to train your people and to create a network of Security Champions, volunteer developers who relay good security practices within their team.

1. Security Champions

   Build the network step by step: recruitment, training, animation, impact measurement.

2. Team training

   Training path, CTF (Capture The Flag), gamification, progressive skills growth.

---

Part 4, Measure

Goal: steer your transformation with data.

What is not measured does not improve. This part teaches you to implement the DORA metrics and the security KPIs: where to plug in the collection, who reads the dashboard, and how a measurement becomes a decision rather than one more chart. What these indicators are, their history and their fifth measure are covered in the lesson DORA metrics, which is the source: this page does not redefine them, it puts them into practice.

1. DORA metrics

   Implement the 4 historical metrics (Deployment Frequency, Lead Time, Change Failure Rate, Failed Deployment Recovery Time) and understand the recent evolution of the model.

2. Security KPIs

   Security metrics: MTTD (mean time to detect a vulnerability), vulnerability MTTR (mean time to fix, not to be confused with the former DORA MTTR renamed Failed Deployment Recovery Time), scan coverage, security debt.

---

Part 5, Deliver

Goal: automate delivery to ship value continuously.

This is the technical practice of the path. This part covers CI/CD, GitOps and SLIs/SLOs (service level indicators and objectives) to deliver quickly and reliably, without sacrificing stability to speed.

1. CI/CD

   From code to production. Pipeline architecture, security gates, continuous deployment strategies.

2. GitOps

   Git as the source of truth. ArgoCD, Flux, automatic reconciliation of the desired state.

3. SLIs, SLOs & Error Budgets

   Define and steer reliability with measurable objectives rather than a "zero incident" requirement.

---

Appendix, DevOps careers

Goal: understand the different roles and their responsibilities.

The jobs of the DevOps and DevSecOps ecosystem each have their own page on this site: their responsibilities, the missions that follow from them, the skills expected with their level, and the courses that teach them. The career paths catalogue presents them all.

Each page details a position: the Site Reliability Engineer for reliability, the Platform Engineer for the internal platform, the DevSecOps Engineer for built-in security, the CI/CD Engineer for delivery, the Cloud Engineer for infrastructure and the Linux Administrator for the system foundation. Release Manager, DevOps Architect and FinOps have no career path page, for lack of a course that covers them: the matrix of roles and Team Topologies places them in an organisation all the same.

---

Where to start?

The table below spares you from reading the five parts in order when it is not necessary. It matches a common starting situation with a shortened reading route, so that you go straight to the chapter that answers your most pressing need.

Your situation	Recommended route
Complete beginner	Read the Fundamentals first, then come back here
New project	Part 5 (CI/CD) then Part 1 (4 pillars)
Existing organisation	Part 1 (Audit) then Part 2 (Team Topologies)
Collaboration problem	Part 2.4 (Collaboration) then Part 3 (Training)
Need to justify the ROI	Part 4 (Metrics) then Part 1 (Audit)
Recruit or move on	Careers appendix

Swipe to see more

---

Links with the Fundamentals

This implementation path builds on the theoretical concepts presented in the Fundamentals. The following table makes the explicit bridge between each notion and its practical application in this path, so that you do not have to reread the theory if you have already absorbed it.

Concept (Fundamentals)	Application (Implementation)
Three Ways & CALMS	Team structure (Part 2)
Maturity and roadmap	Maturity audit (Part 1)
DORA metrics	DORA implementation (Part 4)
Shift-Left	Secure pipeline (Part 5)
SLOs, SLIs & Error Budgets	SRE in practice (Part 5)

Swipe to see more

Key points

• A DevSecOps transformation that skips the assess step (DSOMM audit, 4 quality pillars) moves blind and cannot demonstrate progress.
• Team Topologies (4 team types, 3 interaction modes) became in 2026 the common vocabulary to organise delivery teams, even before the choice of tools.
• Platform Engineering is the logical sequel to Team Topologies: the internal platform is set up as a product, by a dedicated team.
• Culture (Security Champions, training) counts as much as technique: a perfect pipeline on a siloed organisation transforms nothing.
• The DORA metrics are defined in the Fundamentals and implemented here: where to plug in the collection, who reads the dashboard, and what you then decide.
• CI/CD, GitOps and SLOs form the technical foundation of continuous delivery: they come last, once organisation and culture are in place.
• The 6 career path pages of the appendix describe six roles (SRE, platform engineer, DevSecOps engineer...), and the matrix of roles and Team Topologies places them in an organisation.
• The Where to start table spares you from reading the 5 parts in order when a precise urgency (ROI, collaboration, new project) takes priority.

Technical guides

The detailed technical implementation guides (code analysis, secrets, supply chain, monitoring) are in the Secure (in French) and Observability (in French) sections.

×

See in the glossary →