Qu'est-ce que le DevSecOps ?

L'audit qui arrive deux jours avant la release

Tout le monde a vécu cette scène au moins une fois. La release est prévue pour vendredi, l'équipe a tenu tous ses jalons, le code passe les tests d'intégration. Mardi, l'équipe sécurité débarque avec un rapport de cinquante pages : trois CVE critiques sur des dépendances vieilles de deux ans, un secret AWS oublié dans un .env commité l'an dernier, des permissions trop larges sur un bucket S3. La release glisse de trois semaines. Tout le monde s'accuse mutuellement.

Le DevSecOps ne propose pas de mieux faire ce contrôle final : il propose de le supprimer. Plutôt qu'un audit en bout de chaîne, la sécurité devient une vérification continue distribuée tout au long du cycle de développement, partagée entre développeurs, ops et spécialistes sécurité.

Le DevSecOps en une phrase

DevSecOps = DevOps + Sec. On garde tout ce que le DevOps apporte (CI/CD, IaC, automatisation, observabilité), et on étend ces mêmes pratiques à la sécurité, qui devient un objectif d'équipe au même titre que la vélocité et la fiabilité.

Concrètement, ça veut dire trois choses :

1. La sécurité est un critère de done, pas une étape. Un ticket n'est livrable que s'il passe les contrôles de sécurité, au même titre qu'il doit avoir des tests qui passent.
2. Les contrôles sont automatisés et précoces. Pas un audit manuel de fin de cycle, mais des scans qui tournent à chaque commit.
3. La responsabilité est partagée. Les devs, les ops et les spécialistes sécurité travaillent ensemble. Personne ne dit "c'est pas mon problème".

DevOps vs DevSecOps : ce qui change concrètement

DevOps a fusionné le développement et les opérations autour d'un pipeline automatisé. DevSecOps ajoute la sécurité dans le même pipeline, sans le casser. Le diff ressemble à ça :

Aucune ligne ne remplace l'autre. DevSecOps étend. C'est pour ça qu'on dit "DevSecOps c'est juste du DevOps fait correctement" : techniquement vrai, mais le décalage culturel est réel et c'est lui qui pose le plus de problèmes en pratique.

Et la sécurité traditionnelle alors ?

Le tableau caricature un peu, mais il rend visible le décalage : passer au DevSecOps n'est pas qu'une question d'outils, c'est une redistribution de la responsabilité.

Les quatre piliers

Shift-left : déplacer les contrôles vers la gauche

Plus tôt une vulnérabilité est détectée, moins elle coûte. Concrètement : un scanner SAST tourne à chaque pull request plutôt qu'une pentest manuelle deux semaines avant la mise en prod. Un linter de Dockerfile bloque les images qui tournent en root. Un hook pre-commit refuse les commits qui contiennent des chaînes ressemblant à des clés AWS.

Responsabilités partagées

Les devs apprennent l'OWASP Top 10. Les ops apprennent à lire un avis CVE et à évaluer s'il s'applique à leur stack. Les spécialistes sécurité passent du rôle de gardien à celui de coach. Ils écrivent des règles Semgrep custom, font du pair-programming sur les fonctions critiques, font évoluer les checklists d'architecture. Personne ne devient expert de tout, mais plus personne ne dit "c'est pas mon problème".

Automatisation continue

Si un contrôle de sécurité est manuel, il est sauté la moitié du temps. Le DevSecOps mise sur l'automatisation : SAST, SCA, scanning de conteneurs, vérification de signatures, audit de configuration : tout passe par la CI/CD. La règle implicite : un check qu'un humain doit lancer à la main n'est pas un check, c'est un souhait.

Security by Design

La sécurité entre dans la phase de conception, pas en revue post-mortem. Au moment où on dessine l'architecture d'un service, on se pose les questions : quel est le périmètre d'authentification ? Quelles données sont en transit ? Où vivent les secrets ? Le threat modeling devient une étape normale d'un design doc, pas un atelier exceptionnel piloté par un consultant externe.

Le DevSecOps selon ton rôle

La promesse de "responsabilité partagée" reste abstraite tant qu'on ne dit pas ce que ça change pour chacun au quotidien. Tour des principaux profils.

Développeur (backend, frontend, mobile)

Ton job ne devient pas "faire de la sécu", il devient "ne pas laisser passer les évidences". Concrètement :

• Tu connais l'OWASP Top 10, au moins les 3-4 catégories qui touchent ton stack (injection, auth cassée, secrets exposés).
• Tu lis les retours du SAST sur ta PR comme tu lis ceux du linter : tu fixes ou tu argumentes (avec un commentaire // nosem justifié, par exemple).
• Tu n'écris jamais de secret en dur dans le code. Tu utilises le mécanisme de secrets de ton orchestrateur (K8s Secrets, Vault, AWS Secrets Manager).
• Tu mets à jour les dépendances que Dependabot/Renovate signale, dans la semaine. Pas dans six mois.

Full-stack

Tout ce qui précède, plus la zone d'interface :

• Côté front : politique CSP, sanitisation des entrées, gestion des tokens (jamais en localStorage pour des sessions sensibles).
• Côté back : validation des inputs côté serveur (jamais "je valide juste côté client"), rate limiting sur les endpoints exposés.
• Tu portes la cohérence du modèle d'authn/authz d'un bout à l'autre. C'est souvent là que les CVE se cachent.

Ops / SRE / Infra

Tu déplaces des contrôles de la prod vers le pipeline :

• Tes manifests Kubernetes/Helm passent par kubeconform, kube-score, ou OPA/Conftest avant déploiement.
• Tu scannes ton IaC (tfsec, checkov) : pas de bucket S3 public par défaut, pas de SG 0.0.0.0/0 sur SSH.
• Tu maintiens l'inventaire des images en runtime et tu surveilles les CVE qui apparaissent dessus (Trivy Operator, Falco).
• Tu mets en place la rotation des secrets et la fédération d'identité (OIDC entre runners CI et cloud, plutôt que des clés long-lived).

Spécialiste sécurité (AppSec, SecOps)

Ton rôle change le plus. Tu passes de gardien à coach :

• Tu écris des règles Semgrep/CodeQL custom adaptées au business, plutôt que de relire le code à la main.
• Tu fais du pair-programming sur les fonctions sensibles (auth, paiement, accès aux données personnelles).
• Tu maintiens les playbooks d'incident et tu animes les post-mortems sécurité.
• Tu choisis les outils du pipeline et tu calibres leur niveau de bruit (un SAST qui crie sur tout est ignoré au bout d'une semaine).

Business Analyst / Product Owner

Tu n'écris pas de code, mais tu décides de ce qui est livré. Donc :

• Tu intègres les exigences de sécurité dans les user stories, pas dans un document séparé "non-functional requirements" que personne ne lit.
• Tu connais le cadre réglementaire qui s'applique à ton produit (RGPD, PCI-DSS, HDS, eIDAS, NIS2…) et tu sais quelles features touchent ces exigences.
• Tu écris des abuse cases en parallèle des user stories : "En tant qu'attaquant, je veux récupérer la liste des emails clients via cet endpoint pour...". Ça oriente l'implémentation et les tests.
• Tu arbitres les compromis vélocité/sécurité avec le tech lead, en étant informé plutôt qu'en aveugle.

Tech Lead / Manager

Tu portes la cohérence transverse :

• Tu maintiens le seuil de tolérance aux vulnérabilités (par exemple : "aucune CVE critical ouverte plus de 7 jours en prod").
• Tu dimensionnes la dette de sécurité dans le backlog, comme la dette technique.
• Tu garantis le temps de formation : un dev junior ne peut pas implémenter de l'auth sans avoir lu OWASP ASVS d'abord.
• Tu négocies les exceptions documentées (avec date d'échéance) plutôt que des bypass silencieux.

À quoi ressemble un pipeline DevSecOps en pratique

Voici les étapes qu'on retrouve dans la plupart des pipelines, avec un ou deux outils représentatifs par étape. Aucun n'est obligatoire ; l'idée est de comprendre le rôle joué.

Au moment du commit (côté développeur)

• Détection de secrets : Gitleaks ou TruffleHog en pre-commit hook.
• Linters de sécurité : règles ESLint/Bandit/RuboCop selon le langage.

Au build (CI)

• Analyse statique (SAST) : Semgrep ou SonarQube détectent les vulnérabilités dans le code applicatif.
• Analyse de composition (SCA) : Renovate ou Dependabot ouvrent des PRs automatiques pour les dépendances vulnérables.
• Scan de conteneurs : Trivy ou Grype scannent les images avant publication.

Au déploiement

• Politique en tant que code : OPA / Conftest valident les manifests Kubernetes (pas de privileged: true, pas d'image :latest, etc.).
• Signature et provenance : Cosign signe les images, Sigstore atteste leur origine.

En production

• Monitoring runtime : Falco détecte les comportements suspects dans les conteneurs, Trivy Operator scanne en continu les workloads pour les nouvelles CVE.
• Audit de configuration : Lynis ou OpenSCAP vérifient la conformité des hôtes.

Aucun de ces outils n'est magique pris isolément. Leur valeur vient de leur intégration dans le pipeline et du fait que leurs résultats remontent là où la décision se prend : la pull request, pas un dashboard que personne ne regarde.

La supply chain : la nouvelle frontière

Les attaques récentes (xz-utils en 2024, log4shell en 2021, SolarWinds en 2020) ont déplacé l'attention vers la chaîne d'approvisionnement logicielle. Sécuriser son code ne suffit plus si une dépendance transitive ouvre un backdoor. D'où l'émergence de pratiques nouvelles :

• SBOM (Software Bill of Materials) : la liste exhaustive de tout ce qu'un binaire contient. Outils : Syft, CycloneDX.
• VEX (Vulnerability Exploitability eXchange) : permet de dire "cette CVE existe dans la dépendance, mais elle n'est pas exploitable dans notre contexte". Sans ça, on noie les équipes sous le bruit.
• SLSA (Supply-chain Levels for Software Artifacts) : un cadre qui note la maturité d'une chaîne de build, du niveau 0 (rien) au niveau 4 (build hermétique reproductible).

C'est probablement le pan le plus jeune du DevSecOps, et celui qui évolue le plus vite. Pour un projet débutant, commencer par générer un SBOM à chaque build est déjà une marche significative.

Points clés

• DevSecOps = DevOps + Sec : on étend les pratiques DevOps (CI/CD, IaC, automatisation, observabilité) à la sécurité, sans casser le pipeline existant.
• Différence concrète avec DevOps : tests SAST/SCA, scan IaC, signature des artefacts, détection runtime ; tout ça s'ajoute sans remplacer.
• Quatre piliers : shift-left, responsabilités partagées, automatisation continue, security by design.
• Chaque rôle a sa part : du dev qui lit l'OWASP Top 10 au BA qui écrit des abuse cases, en passant par l'ops qui scanne son IaC et le tech lead qui dimensionne la dette de sécurité.
• La supply chain (SBOM, SLSA, signatures) est la frontière actuelle : les dépendances sont souvent un angle mort plus dangereux que le code maison.
• Le DevSecOps est d'abord culturel. Les outils suivent, ils ne précèdent pas.