This career stage, Operational DevSecOps, turns the basics of the foundation (Linux, Git, containers) into concrete operational practices. The DevSecOps course is its guided programme, lesson by lesson. It is aimed at engineers who already know how to deploy an application and now want to secure the delivery flow end to end: shift-left security, a CI/CD pipeline with security gates, secrets management, SBOM and supply chain, GitOps deployment, observability and incident management. You will learn to reason both as a developer and as a defender, without slowing your deliveries. Nine skill blocks structure this stage, from DevSecOps fundamentals to the blameless postmortem.
Estimated duration: 80 to 100 hours depending on your initial CI/CD experience.
What you will learn
- Build security into the whole development cycle with shift-left and STRIDE threat modeling
- Build a CI/CD pipeline with SAST, DAST, SCA and secrets detection
- Generate an SBOM and sign your artefacts with Sigstore/Cosign to reach SLSA level 1 to 2
- Deploy continuously with GitOps (ArgoCD or Flux)
- Measure reliability with SLOs and SLIs rather than by gut feeling
- Handle a production incident and write a blameless postmortem
Block 1: DevSecOps fundamentals
Before building in tools, you need to understand why security fails in teams that work fast, and how to fix it structurally. This first block lays down the common vocabulary (threat, risk, vulnerability) and the decision framework that serves as the foundation for the rest of the stage.
The introduction to DevSecOps shows what changes compared with classic DevOps, and the guide on threats, risks and vulnerabilities gives the words to reason about an attack surface. Next come the structural causes of failure, in why security fails, and how to decide under constraint: accept, reduce or transfer a risk, as explained in the guide on security trade-offs.
Two guides close the block. Shared responsibility says who does what between developers, ops, security and management, and Security by Design shows how to build security in from the design stage, before the first line of code.
Block 2: Shift-left and threat modeling
Shift-left (moving security controls as early as possible in the development cycle, rather than at the end of the pipeline) is not an empty phrase: it is a decision about how work is organised. Knowing how to do threat modeling is the key skill that makes shift-left concrete rather than declarative, by identifying attack scenarios before writing the first test.
The OWASP Top 10, the historical reference for application risks, moved to its 2025 edition: two new categories appear, including software supply chain failures, and Broken Access Control keeps first place. That is a good reason to go through it again even if you already know it by heart.
The Shift-left lesson explains how to shorten the feedback loop and reduce the cost of fixing. Threat modeling with STRIDE gives it a method designed for the backlog and sprint planning, and the OWASP Top 10 applied to DevSecOps shows how to use it in awareness training, code review and quality gates.
Block 3: Security testing
Automated security tests are the heart of the DevSecOps pipeline. SAST (analysing source code without running it), DAST (testing the running application), SCA (analysing third-party dependencies) and fuzzing each have a precise place depending on the moment of the cycle where you want to detect a problem.
The security testing guide says when to use each type of test and how to integrate it in CI. The secure CI/CD pipeline assembles these tests into security gates, with thresholds, false positive handling and artefact signing.
On the platform side, pick the one that fits your context: GitLab CI/CD (in French) and GitHub Actions each have their own course. Whatever the platform, the guide on securing CI/CD pipelines treats the pipeline itself as a target: runner hardening, variable injection, OIDC and supply chain attacks.
Block 4: Secrets management
Secrets (passwords, API keys, access tokens) exposed in logs, Git repositories or Docker images remain a frequent cause of data leaks. Secrets management is an operational subject, not a theoretical one: it concerns the developer who commits a .env file by mistake as much as the administrator who has to renew a compromised key urgently.
The secrets management guide (in French) compares Vault, SOPS and External Secrets Operator, and helps you choose according to your infrastructure. The principle to remember before any tool: a secret never lives in the repository, it is injected at runtime and renewed without redeploying the application.
Block 5: Supply chain and SBOM
Software supply chain security has become unavoidable since the SolarWinds and Log4Shell attacks, and more recent incidents confirm it: the Shai-Hulud npm worm, which appeared in 2025, came back on 19 May 2026 against many packages of the AntV ecosystem (see the incident write-up (in French)). It spreads by reusing the maintainer tokens it steals, without exploiting any technical flaw. A single booby-trapped popular package can contaminate a very large number of downstream projects.
The SBOM (Software Bill of Materials, the complete inventory of a software's components), the SLSA framework (now at version 1.2, with a build track and a source track) and Sigstore signing have become the de facto standards to trace and verify the origin of an artefact. The 2025 edition of the OWASP Top 10 even devotes a whole category to software supply chain failures: this risk has definitively moved beyond the stage of a curiosity for security teams.
The supply chain security guide explains how to produce SBOMs, build attestations and signatures. Vulnerability management takes over once the inventory is known: triage, CVSS and EPSS scores, internal deadlines, exceptions and the link with VEX.
Block 6: GitOps
GitOps structures continuous deployment: Git becomes the single source of truth, and a controller (ArgoCD or Flux) permanently compares the real state of the cluster with the state declared in the repository. Any drift triggers an automatic reconciliation, which makes deployments declarative, traceable and auditable: no more wondering who changed what in production, the Git history answers the question directly.
The guide GitOps: principles, ArgoCD vs Flux and implementation lays down the principles, the reconciliation and the difference between the pull model and the push model, before comparing ArgoCD and Flux.
Block 7: CI/CD: from idea to production
Beyond the tools, understanding the CI/CD philosophy avoids falling into the classic traps: pipelines that take 40 minutes to run, flaky tests (tests that fail randomly with no link to a code change) that erode the team's trust, or manual deployments that betray the promise of continuous delivery.
The definition of a CI/CD pipeline and the distinction between CI and CD lay down the vocabulary, then the pipeline architectures show when to parallelise or move to a matrix. The last two guides are about failure: why pipelines fail, between flakiness and a cycle time that is too long, and the CI/CD anti-patterns that turn a pipeline into an obstacle.
Block 8: Minimal observability
Without observability (the ability to understand the internal state of a system from its outputs: metrics, logs, traces), you deploy blind and every incident turns into groping investigation. The goal of this block is to learn to measure what really matters to your users, not simply what is easy to show on a dashboard.
The observability guide explains what metrics, logs and traces bring and how to combine them. SLOs, SLIs and error budgets turn these measurements into reliability objectives that weigh on decisions. For practice, the observability section (in French) covers Prometheus, Grafana, Loki, Tempo and OpenTelemetry.
Block 9: Incidents and runbooks
Incident management is a DevSecOps skill in its own right, not a subject reserved for on-call teams. Mature teams treat every incident as a learning opportunity thanks to the blameless postmortem (an analysis that looks for the systemic causes of an outage rather than someone to sanction), not as a fault to punish. This discipline is at the heart of SRE (Site Reliability Engineering), which treats reliability as a feature in its own right rather than a mere side effect of operations.
The guide on incidents and postmortems follows the complete cycle: detection, escalation, resolution and analysis. The organisation of on-call shows how to sustain a bearable rotation, and eliminating toil frees the time that repetitive work takes away.
Practical deliverable: Operational project
The personal project of this stage takes the foundation repository and adds the complete security chain: scans, SBOM, signing, GitOps deployment and monitoring. If it runs end to end with no manual intervention, you are ready for the Expert DevSecOps stage.
Point 4 is often the first encounter with Kubernetes, which the Expert stage assumes acquired. If it is new to you, first go through the basics (pod, deployment, service) in the Kubernetes course (in French): the four other points do not depend on it.
No automated check evaluates this project, and the course capstone does not validate it. The notes-api common thread hardens a different service from yours, notes-api, across versions V0 to V11. Depending on the track you follow, Essential or Complete, the common thread does not count the same number of versions. On the Essential track, seven versions belong to this stage: V0 (tested pipeline), V1 (STRIDE), V2 (blocking secrets and SAST), V3 (dependency analysis), V6 (image and infrastructure with Trivy), V10 (dated exceptions and VEX) and V11 (SLO and DORA metrics). The Complete track adds V4 (OIDC), V5 (audited workflows) and V7 (SBOM and provenance).
The common thread checks neither the GitOps deployment with ArgoCD, nor the Grafana dashboard, nor image signing in CI: V8, the only version that deals with signed images, belongs to the Complete track and needs a cluster. These parts of your project are therefore checked by hand.
Key points
- Security built into the pipeline does not slow deliveries down if the gates are well calibrated: blocking on critical severities, informative on the rest.
- Shift-left gains a lot from being combined with threat modeling: without threat modeling, you scan without knowing what to prioritise.
- The OWASP Top 10:2025 adds two new categories, including software supply chain failures: a strong signal that this risk is now central.
- The SBOM (the inventory) and signed provenance via Sigstore/Cosign are the two basic building blocks to prove the integrity of an artefact and aim for SLSA level 2.
- npm worms such as Shai-Hulud are a reminder that the supply chain is also compromised through stolen maintainer tokens, not only through a technical flaw.
- GitOps simplifies deployment auditing: every change is traced in Git, with automatic reconciliation in case of drift.
- Observability without SLOs remains hard to use: define what matters before installing dashboards.
- A well-handled incident produces a blameless postmortem, not a culprit: that is what distinguishes a team that learns from a team that protects itself.