Aller au contenu
DevSecOps Logo Stéphane ROBERT
Docs
Blog

DevSecOps 2026 : monter d'un cran nos exigences

Publié le :

Les attaques se multiplient. SolarWinds, Log4Shell, XZ Utils, compromissions npm, PyPI, Docker Hub… chaque année apporte son lot de catastrophes. En tant qu’acteurs de l’automatisation, nous ne pouvons plus traiter la sécurité comme un sujet « à part », relégué à une équipe spécialisée qu’on consulte en fin de projet.

J’ai moi-même commis cette erreur : pendant des années, j’ai produit des tutoriels et des guides orientés « comment faire fonctionner », sans systématiquement rappeler les implications de sécurité. Un guide Ansible qui montre comment déployer, mais qui ne mentionne pas les risques d’un playbook mal protégé. Un tutoriel Terraform qui provisionne des ressources, mais qui oublie le moindre privilège sur les credentials.

Désormais, la sécurité doit être omniprésente, intégrée dans chaque guide, chaque tutoriel, chaque page de documentation. C’est pourquoi j’ai décidé de prendre un virage important sur ce site : injecter des rappels de sécurité partout où c’est pertinent et développer massivement les contenus dédiés.

Le constat : des outils puissants, des risques amplifiés

Ansible, Terraform, Kubernetes, les pipelines CI/CD… tous ces outils que nous utilisons quotidiennement sont des vecteurs d’attaque privilégiés. Un playbook Ansible compromis peut déployer une backdoor sur des centaines de serveurs en quelques secondes. Un workflow GitHub Actions mal configuré peut exfiltrer tous vos secrets. Une image Docker vérolée peut infecter toute votre chaîne de production.

Nous amplifions tout : les bonnes pratiques comme les mauvaises.

C’est pourquoi vous verrez apparaître dans quelques des encarts comme celui-ci dans les guides techniques :

Ces rappels renverront vers des guides dédiés qui détaillent les bonnes pratiques spécifiques à chaque outil. Un exemple concret avec Ansible.

alt text

Les principes fondamentaux : la base de tout

Avant de parler d’outils, il faut comprendre pourquoi certaines pratiques sont essentielles. J’ai restructuré la section Principes de sécurité pour en faire une vraie introduction pédagogique.

CIA Triad

Confidentialité, Intégrité, Disponibilité : les trois piliers de la sécurité informatique.

Moindre privilège

Ne donner que les droits strictement nécessaires, jamais plus.

Défense en profondeur

Plusieurs couches de protection pour qu’une faille ne soit pas fatale.

Zero Trust

Ne jamais faire confiance par défaut, toujours vérifier.

Ces principes sont la grille de lecture qui permet d’évaluer n’importe quelle configuration, n’importe quel outil.

L’obsession du 0 CVE : absurde ou essentielle ?

On me fait parfois la remarque que viser le “0 CVE” serait une obsession irréaliste. Je comprends l’objection : dans un système complexe, des vulnérabilités apparaissent constamment, et l’idée de zéro faille peut sembler naïve.

Mais le vrai problème n’est pas d’atteindre un hypothétique zéro parfait. Le problème, c’est l’alternative : repousser à plus tard.

La page sur la dette de sécurité détaille ce mécanisme destructeur. Les raisonnements classiques :

  • « On corrigera cette CVE après la release »
  • « Ce compte de service temporaire, on le sécurisera plus tard »
  • « Cette configuration est vulnérable mais personne ne l’exploite »

Chaque report génère :

  • Une vulnérabilité active que les attaquants peuvent exploiter
  • Un coût croissant de remédiation (le contexte s’oublie, le code évolue)
  • Une normalisation du risque (on s’habitue à vivre avec)

Le danger des mouvements latéraux

L’argument « c’est un serveur interne, pas exposé » est particulièrement dangereux. Les attaquants ne rentrent pas par la porte principale : ils trouvent un point d’entrée, puis pivotent de machine en machine.

Le schéma classique d’une attaque :

  1. Compromission initiale : phishing, dépendance vérolée, service exposé
  2. Reconnaissance : l’attaquant cartographie le réseau interne
  3. Mouvement latéral : il exploite les CVE des serveurs « internes »
  4. Élévation de privilèges : il atteint les systèmes critiques
  5. Objectif final : exfiltration, ransomware, persistance

Votre serveur Jenkins non patché « qui n’est pas exposé » ? C’est la cible parfaite pour le mouvement latéral. Votre base de données avec une CVE connue « mais derrière le VPN » ? L’attaquant qui a compromis un poste développeur y a accès.

Chaque CVE non corrigée est une marche d’escalier vers vos systèmes critiques.

C’est pourquoi le Zero Trust et la segmentation réseau sont essentiels : même en interne, on vérifie, on limite, on cloisonne.

L’exemple concret : une CVE critique estimée à 2 jours de correction. Repoussée de sprint en sprint, elle finit par être exploitée 6 mois plus tard. Post-mortem : 3 semaines pour comprendre et corriger. Coût réel : 50x l’estimation initiale.

Viser le 0 CVE n’est pas une question de perfectionnisme. C’est refuser la logique du « plus tard » qui transforme des corrections simples en incidents majeurs.

Les axes de développement

Voici les grandes thématiques que je vais développer dans les prochains mois.

1. DevSecOps : l’approche globale

Avant de parler d’outils, c’est une question de culture et d’organisation.

Contenus prévus :

  • Shift-left security : intégrer la sécurité dès le design
  • Security Champions : former des relais dans les équipes
  • Métriques sécurité : mesurer pour progresser

2. Supply Chain : le risque n°1

Les attaques supply chain sont devenues le vecteur privilégié des attaquants. Pourquoi compromettre une cible quand on peut compromettre ses dépendances ?

Contenus prévus :

  • SBOM (Software Bill of Materials) : générer, analyser, exploiter
  • SCA (Software Composition Analysis) : scanner les vulnérabilités
  • Signature et vérification des artefacts (Cosign, Sigstore)
  • Sécurisation des registries (npm, PyPI, Docker Hub)
  • OpenSSF Scorecard : évaluer la posture sécurité des projets

3. Sécurité Kubernetes

Kubernetes est devenu le standard de facto pour l’orchestration. Mais sa complexité en fait aussi un terrain fertile pour les erreurs de configuration.

Contenus prévus :

  • Pod Security Standards (PSS) : remplacer les PSP
  • NetworkPolicies : implémenter le Zero Trust
  • SecurityContext et Capabilities
  • Runtime Security avec Falco et Tetragon
  • Politiques avec Kyverno et Gatekeeper
  • RBAC : guide complet et bonnes pratiques

4. Sécurité CI/CD

Les pipelines sont des cibles de choix : ils ont accès aux secrets, aux registries, aux environnements de production.

Contenus prévus :

  • Sécuriser GitHub Actions (permissions, runners, secrets)
  • Sécuriser GitLab CI (templates, tokens)
  • Attaques sur les pipelines : cas pratiques

5. Sécurité de l’Infrastructure as Code

Terraform, Ansible, Pulumi… ces outils ont des accès privilégiés. Les sécuriser est critique.

Contenus prévus :

6. Sécurité Cloud

Le cloud amplifie les risques : une mauvaise configuration IAM peut exposer des données critiques à Internet. Le rapport CERT-FR 2025 documente de nombreuses compromissions liées à des erreurs de configuration cloud.

Contenus prévus :

  • IAM : moindre privilège, policies, rôles, fédération d’identité
  • Gestion des secrets cloud (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager)
  • Sécurisation des buckets S3 / Blob Storage : permissions, chiffrement, logging
  • Cloud Security Posture Management (CSPM) : Prowler, ScoutSuite, CloudSploit
  • Network Security Groups et pare-feux cloud
  • Audit et conformité

7. Gestion des incidents

Quand ça arrive (et ça arrivera), il faut être prêt.

Contenus prévus :

  • Détection des incidents
  • Réponse à incident sur une supply chain compromise
  • Playbooks standards (secrets exposés, dépendance vulnérable)
  • Confinement, preuves, communication

Ce qui change concrètement

Des rappels de sécurité dans les guides existants

Chaque guide technique qui manipule des accès privilégiés comportera désormais un encart renvoyant vers les bonnes pratiques de sécurité spécifiques.

C’est déjà le cas pour :

  • Ansible → encart danger + guide dédié
  • Les pages sur les inventaires, variables, collections, lookups, rôles, configuration

Des contrôles de connaissances

J’ai ajouté des quiz de sécurité pour valider la compréhension. Par exemple, le guide Ansible Security inclut maintenant 20 questions sur les bonnes pratiques.

Des liens vers les ressources externes

Chaque guide inclura des liens vers les ressources de référence : opensourcemalware.com ↗ pour surveiller les packages malveillants, OpenSSF Scorecard pour évaluer les projets, etc.

Pourquoi maintenant ?

Parce que les attaques ne vont pas diminuer. Parce que l’automatisation amplifie les risques. Parce que la dette de sécurité s’accumule plus vite que la dette technique.

Et surtout parce que la sécurité n’est pas un frein à la productivité : bien intégrée, elle devient un accélérateur de confiance.

Comment contribuer ?

Si vous repérez un guide qui mériterait un rappel de sécurité, si vous avez des suggestions de contenus, n’hésitez pas à me contacter sur Discord, LinkedIn ↗ ou via GitHub ↗.

La sécurité est l’affaire de tous. Construisons ensemble une documentation qui forme des praticiens conscients des risques et équipés pour y faire face.

Pour aller plus loin

Quelques ressources externes en français pour approfondir ces sujets :

Guides officiels :

Comprendre les menaces :

DevSecOps en pratique :