DevSecOps means building security into every step of software delivery, from design to production, instead of leaving it to an end-of-project audit. This course teaches a method: knowing which risk you are dealing with, which control covers it, where to place it in the chain and how to prove that it works. It is the core course of the site: the other domains provide its foundation or deepen it. It is aimed at a DevOps engineer, a sysadmin or a developer who already knows Linux, Git, containers, CI/CD and the basics of Terraform, and who wants a chain where security is automated and verifiable.
What you will learn
- Analyse the risks of an application and its pipeline with a threat model
- Block flaws, secrets and vulnerable dependencies before they enter the repository
- Harden a CI/CD pipeline: permissions, pinning, short-lived tokens, OIDC (a federated identity that avoids storing a secret)
- Produce a clean image, an SBOM (the inventory of shipped components), a signature and a provenance (who built the artifact, and how) that can be verified
- Replace static secrets with machine identities
- Handle a vulnerability from discovery to closure, and measure the security posture
What problem does this course solve?
Before choosing a tool, you need to name what is blocking. The table sets the visible symptoms, the ones you notice in a post-incident meeting, against the root causes they hide. Reading it this way avoids treating a problem of culture or flow with a purely technical fix, the most common mistake of teams that are starting out.
| Common symptom | What is really missing |
|---|---|
| Modern tools, but incidents that keep recurring | A culture of continuous improvement and blameless postmortems |
| A CI/CD that runs, but releases that are still stressful | Smaller batches and faster feedback |
| Security flaws discovered in production | Security treated as a design constraint, not a final check |
| Scanners plugged in, but no build ever blocked | A decided blocking threshold, and evidence that it works |
| Every team reinvents the wheel | A shared foundation and a common platform |
Who is this course for?
It assumes the DevOps basics are in place and does not teach them again. If one of the prerequisites below is missing, take the course that covers it first: each DevSecOps module points to it instead of repeating it. Kubernetes is not required to start; it is only used at the end of the Complete track.
| Prerequisite | Why | Where to learn it |
|---|---|---|
| Linux | containers and runners run on it | Linux training |
| Git | every control starts at the repository | Git training (in French) |
| Containers | image, registry, execution | Docker training (in French) |
| CI/CD | the pipeline is an asset to secure | GitHub Actions or GitLab CI (in French) |
| IaC | we scan Terraform | Terraform training (in French) |
| Kubernetes, optional | the deployment part of the Complete track | Kubernetes training (in French) |
To place yourself, ask four questions: can you write a multi-stage
Dockerfile, read a CI workflow file, revert a pushed commit, and say what
terraform plan does? Four yeses: start at module 1. One no: go through
the matching course first; a targeted reading is often enough.
A method, not a catalogue of scanners
A course organised tool by tool, an SAST chapter, a DAST chapter, an image scanning chapter, leaves the hardest part to the reader: linking each scanner to the risk it covers. Here, every control is presented in the same order: which risk, which class of control, where to place it, what result it produces, and how to handle that result. The tool comes last, and a single one serves as the reference implementation for each need.
| Need | Reference tool | Why this one |
|---|---|---|
| Secrets in the code | Gitleaks | free, fast, reads the Git history |
| Static analysis | Semgrep | readable rules, SARIF output, the standard results format |
| Dependencies, image, IaC | Trivy | a single binary for three scans |
| IaC misconfiguration | Checkov | wide Terraform coverage |
| Inventory and signing | Syft, Cosign | open standards, Sigstore |
| Encrypted secrets in Git | SOPS | files reviewed in code review |
| Compliance | CINC Auditor | InSpec profiles, free distribution |
| Runtime detection | Falco | graduated project of the CNCF, the foundation that hosts Kubernetes |
All these tools are open source and run locally: no paid cloud is required. The alternatives (detect-secrets, KICS, OpenSCAP, Tetragon) remain documented on the site, outside the course.
The programme in sixteen modules
The course follows the delivery cycle, not the site tree: its lessons come from the security, DevOps, CI/CD, containers and infrastructure as code sections. The first three modules set the frame (culture, delivery, why security belongs in the flow), the next ten secure the chain in the order a change travels through it, and the last three teach you to measure, to scale and then to demonstrate everything. Each module answers one question, and the right-hand column gives its first lesson on the Essential track.
| Module | The question | Start with |
|---|---|---|
| Culture and flow | Why DevOps, and how does value flow? | What is DevOps? |
| The delivery system | How does a change reach production? | What is a CI/CD pipeline? |
| DevSecOps fundamentals | Where should security enter the cycle? | DevSecOps |
| Threat modeling | What do we protect, and from whom? | Threat, risk, vulnerability |
| Code and dependencies | How do you stop a flaw or a secret from getting in? | Automated security testing |
| Secrets and machine identity | How do you do without static secrets? | The problem with static secrets |
| Securing CI/CD | Can you trust what runs the build? | Implicit trust |
| Build, containers and IaC | How do you ship a sound image and infrastructure? | Dockerfile best practices |
| Software supply chain | What do we ship, and who built it? | Supply chain security |
| Controlled deployment | How do you deploy only what you verified? | Encrypting secrets with SOPS (Complete) |
| Runtime security | What happens once in production? | Container security |
| Vulnerabilities and compliance | How do you take a CVE through to closure? | Vulnerability management |
| Observe and respond | What do you do when the system degrades? | Observability |
| Measure and steer | Are delivery and security improving? | DORA metrics |
| Scale across teams | How do you extend the practice to every team? | Security Champions (Complete) |
| Capstone | The whole chain, on a single repository | The common thread |
Secrets and machine identity come before pipeline security on purpose: a pipeline without static secrets relies on OIDC, and you need to understand the secret zero problem to see why. The detailed programme, lesson by lesson, with your progress, is on the My course page.
Two tracks: Essential or Complete
The Essential track keeps the backbone: one lesson per essential practice, from the culture to the runtime, without Kubernetes. The Complete track adds the deep dives, the Kubernetes part of deployment and detailed governance. The selector on the My course page filters the display; your progress stays the same.
One repository, hardened module after module
Rather than isolated exercises, the course follows a single product: a small, deliberately flawed application, with a secret in its history, a vulnerable dependency, a Dockerfile running as root, an over-permissive Terraform and an over-privileged pipeline. Each module fixes one layer, and the chain goes from v0, unsecured, to a version that is signed, attested and then monitored.
The lessons are tracked one by one in My course, and quizzes cover most of them. Two guided labs specific to the course cover the hardened pipeline and the verifiable build; the lessons taken from the Kubernetes and Terraform courses carry those courses' labs.
How do you prove what you know?
A quiz checks that you understood why, a guided lab that you know how to do it, a challenge that you can do it without the procedure. The final proof comes from the capstone: it does not grade the commands typed, it checks the final state of the repository. Secret gone from the history, scanners that really block, SBOM present, valid signature, unsigned image refused.
To go further, outside the course
These pages are not part of the progression, so that it stays finishable. They extend a module when a topic concerns you directly:
- Code: fuzzing (in French), OSV-Scanner (in French)
- Pipeline: self-hosted runners, Jenkins
- Containers and IaC: namespaces, capabilities, seccomp (in French), OPA and Conftest (in French)
- Supply chain: Sigstore (in French), in-toto (in French), Syft (in French)
- Secrets: OpenBao (in French), Kubernetes secrets (in French)
- Runtime: Kubernetes audit logs (in French)
After the course: career levels and specialisations
The course provides the shared foundation. The DevOps section of the site also offers three career roadmaps, which go well beyond the course: they also cover reliability, delivery and team organisation. They help you place a role, not replace the programme you follow.
- Level 1, Foundation (in French): DevOps culture, flow, security basics and SRE (Site Reliability Engineering).
- Level 2, Operational DevSecOps (in French): secure pipeline, secrets, supply chain, GitOps, observability, incident management.
- Level 3, Expert and specialisations (in French): governance, maturity, Platform Engineering, policy as code.
DevSecOps is not a single job: it is a foundation that leads to distinct paths depending on whether you favour application security, reliability, the platform, the cloud or pipelines. The first five specialties of the table have their own page, with their responsibilities and their path, in the career paths catalogue; the architect and FinOps have none, as no course on this site covers them.
| Specialty | Mission | Target certifications |
|---|---|---|
| DevSecOps Engineer | Shift-left security, SAST/DAST, supply chain | CKS, Certified AppSec |
| SRE | Reliability, SLO/SLI, on-call, toil reduction | CKA, CKAD |
| Platform Engineer | IDP, Golden Paths, self-service infrastructure | CKA, Terraform Associate |
| CI/CD Engineer | Pipelines, artifacts, continuous deployment | GitLab Certified, GitHub Actions |
| Cloud Engineer | Multi-cloud, IaC, migrations | AWS SAA, GCP ACE, AZ-104 |
| DevSecOps Architect | Standards, governance, design for failure | CKA + CKS + multi-cloud |
| FinOps Engineer | Cloud costs, rightsizing, chargeback | FinOps Certified Practitioner |
A certification validates a body of knowledge recognised by recruiters; it never replaces hands-on experience of real incidents. Aim for it once the level that prepares for it is acquired: an advanced exam passed without the foundations leaves blind spots that the first incident reveals.
What does the site's DevOps section contain?
This course is also the entry point of the site's DevOps section, written in French. Its three blocks can be read independently of the course, depending on the need: understanding the concepts, putting them into practice in an organisation, or keeping up with a fast-moving ecosystem.
| Part | What it brings |
|---|---|
| Fundamentals (in French) | The conceptual framework: culture, flow, built-in security, reliability, with no specific tooling |
| Implementation (in French) | Organisational practice: maturity, teams, metrics, delivery |
| Tech watch | Keeping up to date with the DevSecOps ecosystem |
Other sections extend the course on topics that deserve their own path: securing (hardening, RBAC, PKI), observability, infrastructure as code, cloud and orchestrators, home of Kubernetes, all in French.
What this course stands for
Security is proven, not declared. A scanner built into the pipeline that has never blocked a build protects nothing: I prefer a single control that really breaks delivery to five tools producing reports that nobody reads.
The supply chain is not an optional chapter. Recent incidents, tj-actions, the npm worms of the Shai-Hulud family, came through the pipeline and the dependencies, not through an application flaw. That is why SBOM, signing and provenance are at the heart of the course, on a par with dependency scanning.
A badly handled false positive costs more than a real one. A team that ignores a hundred alerts ends up ignoring the hundred and first, the real one. I advise against suppressing an alert without an expiry date or a written justification: it is a debt that is no longer visible.
Key points
- DevSecOps builds security into every step of delivery, not at the end.
- The course teaches a method: risk, control, placement, result, handling.
- It assumes Linux, Git, containers, CI/CD and the basics of Terraform, and points to their courses.
- Sixteen modules follow the delivery cycle, on two tracks, Essential and Complete, with secrets before the pipeline.
- A single repository is hardened module after module, up to the capstone.
- All the reference tools are open source and run locally.
- After the course, three career levels and seven specialisations extend the shared foundation.