Many teams think they are doing DevOps because they have a CI, containers and automated deployments. Yet releases stay risky, security arrives too late, incidents repeat and trade-offs are made blind.
The problem does not come from the tools. It comes from the lack of a shared mental framework.
This path lays the DevSecOps fundamentals: understanding the flow, building security in as a design constraint, steering reliability with measurable objectives. No Jenkins, no Kubernetes here, only the foundations that give meaning to those tools and to the decisions around them.
Once these foundations are in place, the DevSecOps Socle framework (in French) turns this security into concrete, auditable requirements, from code to cloud: 414 requirements across 16 domains, to move from culture to evidence.
What does this path solve?
It is not a catalogue of notions to tick off. It is a diagnosis that starts from the symptoms teams live with every day: stress at deployment, flaws found too late, incidents that repeat. The table below links each symptom to its root cause and to the pillar that addresses it.
| Observed symptom | Root cause | Answer in this path |
|---|---|---|
| Stressful deployments, teams blaming each other | Siloed culture, no shared responsibility | Pillar 1, Understand |
| Big-batch deliveries, late feedback, insufficient tests | Poorly designed flow, lack of shift-left | Pillar 2, Speed up |
| Flaws detected too late, security seen as a brake | Security treated as a final check, not a design constraint | Pillar 3, Secure |
| Repeating incidents, exhausting on-call, no improvement | Reliability not steered by measurable objectives | Pillar 4, Make reliable |
| Every team reinvents the wheel, practices impossible to spread | No systems view and no common platform | Horizon, Industrialise |
What will you be able to do after this path?
This path gives you three core skills: explain the DevOps stakes to every audience, design reliable and secure delivery, and steer with recognised metrics. It is accessible as soon as you have basic experience in development or system administration, with no prior expertise in security or SRE.
- Explain DevOps, DevSecOps and SRE without confusing them, including to non-technical people
- Design delivery that is smoother, safer and more observable
- Steer with DORA metrics, SLOs/SLIs and a maturity roadmap
What sets this path apart
Most resources treat DevOps, security and reliability as three separate subjects. This path deliberately links them.
- Delivery and security are not opposed: well-integrated security speeds you up, it does not slow you down.
- The supply chain changes how you think about pipelines: signing, tracing and attesting are part of modern delivery.
- Reliability is steered, not endured: SLOs, error budgets and observability are velocity tools as much as stability tools.
- Tools without a mental framework fix nothing: this path builds the framework before pointing to the tools.
- AI amplifies what already exists: the DORA 2025 report confirms it, artificial intelligence speeds up a mature team and worsens the weaknesses of a struggling one, it does not replace the framework.
The 4 pillars of the DevSecOps foundation
This path is organised into four progressive pillars, from the most conceptual (understand) to the most operational (make reliable), extended by an industrialisation horizon at the scale of the organisation. Each pillar builds on the previous one: you cannot properly secure a flow you have not understood, or make reliable a system delivered without discipline. The diagram below shows these five stages, the four pillars then the horizon, with the themes of each.
Pillar 1, Understand
3–4 hours
DevOps is not a method to apply mechanically. Before choosing its tools, you must understand why this movement exists, what it measures and how it differs from Agile and SRE. The DORA model has moreover evolved since the four historical indicators: a fifth, the Deployment Rework Rate (the share of deployments that actually fix a bug introduced earlier), was added in 2024 and is now benchmarked in the 2025 report, proof that even the fundamentals move.
The pillar starts with DevOps culture, its origin and what it is not, then gives the two reading grids that structure everything else: the Three Ways and CALMS. The DevOps, Agile and SRE page then draws the boundary between three approaches that are often confused. The DORA metrics bring the measurement, and the DevOps anti-patterns close the pillar on the traps that sabotage even a well-tooled transformation.
Pillar 2, Speed up
3–4 hours
Delivering more often paradoxically makes deployments less risky. This pillar explains why, and introduces the concepts of value stream, feedback loops and shift-left that make the difference between a team that endures its deliveries and a team that masters them.
The thread starts from the value stream: spotting bottlenecks and reducing batch size. The feedback loops explain how to learn fast, shift-left moves checks as early as possible, and the testing strategies build the safety net that makes these frequent deliveries bearable. Each page builds on the previous one: fast feedback is useless without tests to produce it.
Pillar 3, Secure
5–6 hours
Security is not a separate chapter. It is a design constraint that runs through delivery, the pipeline and the supply chain. This pillar covers the vocabulary, the trade-offs, automated tests and artefact traceability, the foundations of applied DevSecOps. The 2025 overhaul of the OWASP Top 10 is a good indicator: misconfigurations and software supply chain failures climb the ranking, proof that risks evolve as fast as practices.
The pillar opens with the introduction to DevSecOps and the vocabulary of risk, then looks squarely at why security fails, which trade-offs it imposes and who carries the responsibility. The practices follow: security by design, threat modeling with STRIDE, the OWASP Top 10 and automated security testing. The pillar ends on the delivery chain itself, with the secure pipeline and supply chain security: SBOM, signing and provenance of artefacts.
Pillar 4, Make reliable
4–5 hours
Delivering fast a system that goes down is still delivering fast. SRE brings the tools to steer reliability: SLOs/SLIs, error budgets, observability, blameless postmortems. This pillar bridges delivery and operations.
The introduction to SRE lays down the principles, then SLOs, SLIs and error budgets provide the tool for trading off new features against stability. Observability supplies the signals that measure them. The last three pages deal with day-to-day operations: eliminating toil, handling incidents and postmortems without blame, and organising sustainable on-call duty.
Horizon, Industrialising at scale
The four pillars work well inside one team. The real difficulty starts when you have to spread them across the organisation: preventing every team from reinventing the wheel, building a common platform, assessing its maturity and choosing where to start. This is the purpose of Platform Engineering, which today structures the industrialisation effort in most mature organisations.
Here we keep the why of three subjects. Maturity and roadmap explains why you should locate your DevSecOps level before choosing the next steps. Platform Engineering exists because an internal platform reduces the cognitive load of product teams by giving them a paved path. Security Champions exist because security does not spread by decree, but through relays in every team.
The how belongs to the organisational path Implementing: measuring your level with the OWASP DSOMM audit, building the champions network, building the platform and training the teams.
Where to start depending on your profile
The right entry point into this path depends on your profile and on what you already master: an experienced developer does not have the same gaps as a security engineer or a manager. The five tabs below suggest an entry route suited to each, to avoid revisiting notions you already have or, conversely, skipping essential basics.
Follow the four pillars in order, starting with the Understand pillar. Do not skip culture: it is what gives meaning to everything else, including the tools you will adopt afterwards.
Start with: DevOps culture
You master Git, CI/CD and testing? Skim Pillar 1, then concentrate on security (Pillar 3) and reliability (Pillar 4).
Start with: Introduction to DevSecOps
You know security but not DevOps? Pillars 1 and 2 are essential to understand the culture and the flow. Pillar 3 will connect with your skills.
Start with: DevOps culture
Validate Pillar 4, where you will find familiar landmarks: SLOs, error budgets, postmortems. Then explore Pillar 3 to bring security into your operating practices.
Start with: SLOs, SLIs and error budgets
Focus on the strategic aspects: DORA metrics, why security fails, SLOs/error budgets, maturity and roadmap.
Start with: DORA metrics
What this path does not do
This path is not a tool tutorial. You will not find a Kubernetes configuration, a GitLab CI pipeline or Trivy rules here. Those guides exist: you will find them further down, in the section "After this foundation, two directions". This path first builds the mental framework that makes those tools useful and those choices informed.
Key points
This path builds a shared mental framework before moving on to the tools. Here are the essentials to keep in mind before you dive into the four pillars, or before you move on to the operational stage, the one about tools.
- Culture comes before tools: without shared responsibility between Dev, Ops and Sec, no tool removes silos.
- Flow is steered: reducing batch size and shortening feedback loops makes deployments less risky, not more.
- Security is a design constraint, not a final check: shift-left and security by design cost less than late remediation.
- The supply chain is part of the scope: signing, tracing and attesting artefacts are now basic practices, not a luxury.
- Reliability is measured: SLOs, SLIs and error budgets turn a vague feeling into an arbitrated decision.
- AI amplifies what already exists: it speeds up a mature team and worsens the dysfunctions of a struggling one, according to the DORA 2025 report.
- Industrialisation is the next stage: once the four pillars are in place, the real difficulty is spreading them at the scale of the organisation.
After this foundation, two directions
Once the foundations are laid, two paths open depending on your immediate priority. The first goes through implementation: CI/CD pipeline, code security, supply chain. The second structures and steers the effort over time: observability, tool landscape, maturity roadmap.
Implementing
These guides move from concept to practice: they show how to configure a pipeline, set up code analysis or sign artefacts with real tools.
For the pipeline, the starting point is the CI/CD overview, which points to the GitHub Actions, GitLab CI and ArgoCD courses. Code analysis gathers the SAST, DAST and SCA tools with their integration, and the supply chain section details Sigstore, SBOMs and SLSA through to the full implementation.
Structuring and steering
These guides help keep the effort alive after the start: measure, equip and raise the team's maturity over time.
Observability (in French) puts metrics, logs and traces into practice. The tool landscape (in French) sorts the DevOps tools by category with their selection criteria. To decide what to continue with, the compass is the Horizon above, and the organisation of the effort is read in the Implementing path.
Further resources
These resources are not essential to follow this path, but they bring a solid theoretical foundation for anyone who wants to go further: reference reading and certifications recognised by the industry.
Reference books
These books shaped modern DevOps and SRE thinking. They come up constantly in conferences and training courses: better to know them, even without having read them all in full. The scientific approach of Accelerate directly inspired the DORA 2025 report cited above.
- The Phoenix Project (Gene Kim), Narrative introduction to DevOps
- The DevOps Handbook (Gene Kim et al.), Complete practical guide
- Accelerate (Nicole Forsgren), The science behind the DORA metrics
- Site Reliability Engineering (Google), SRE practices
- Security Chaos Engineering (Aaron Rinehart), A proactive approach to security
Aligned certifications
These certifications validate skills complementary to this path, from beginner to advanced level. They do not replace practice but structure a recognised skills progression plan for recruiters.
| Certification | Level | Focus |
|---|---|---|
| DASA DevOps Fundamentals | Beginner | DevOps culture, CALMS, Three Ways |
| Certified DevSecOps Professional (CDP) | Intermediate | Secure pipeline, SAST/DAST/SCA |
| Google Cloud Professional Cloud DevOps Engineer | Advanced | SRE, SLO, observability |
| SANS SEC540 | Advanced | Cloud Native Security, Kubernetes, AI automation |