Aller au contenu principal

Incidents réels + FAQ complète

Résumé : quatre incidents ont façonné le DevSecOps moderne — Equifax a imposé la gestion des correctifs, SolarWinds a révélé la fragilité de la chaîne de construction, Log4Shell a démontré que personne ne sait ce qu'il utilise, et la backdoor xz a montré qu'un attaquant patient peut devenir mainteneur d'un projet critique. Cette leçon les analyse, puis répond aux 14 questions fréquentes.

1. Equifax (2017) — le cas d'école du correctif non appliqué​

Ce qui rend ce cas si instructif, c'est sa banalité. Il n'y a eu aucune vulnérabilité inconnue, aucune technique d'attaque sophistiquée, aucun génie de l'informatique. Une faille publique, un correctif disponible depuis deux mois, et un processus qui n'a pas fonctionné.

La question à se poser : combien de temps met votre organisation à appliquer un correctif critique ? Si vous ne connaissez pas la réponse, c'est probablement plus long que vous ne le pensez.

2. SolarWinds (2020) — la chaîne de construction compromise​

Ce que cet incident a changé fondamentalement : jusque-là, on considérait qu'une mise à jour signée par un éditeur reconnu était fiable. SolarWinds a démontré que la signature ne garantit que l'origine, pas l'intégrité du processus qui a produit l'artefact. C'est précisément le problème que le cadre SLSA cherche à résoudre, en apportant des garanties sur la construction elle-même.

3. Log4Shell (2021) — personne ne sait ce qu'il utilise​

La leçon 3 est celle qu'on n'attend pas dans un cours de sécurité, et elle est essentielle. Pendant Log4Shell, la vitesse de correction a dépendu directement de la maturité de la chaîne de livraison. Les équipes capables de déployer en vingt minutes ont corrigé le jour même. Celles qui avaient besoin de trois semaines pour une mise en production sont restées exposées trois semaines.

Un bon pipeline CI/CD est une capacité de sécurité, pas seulement un outil de productivité. C'est le lien direct entre notre cours CI/CD et celui-ci.

4. La backdoor xz (2024) — l'attaquant patient​

Cet incident est le plus troublant des quatre, pour deux raisons. D'abord, il a été découvert par hasard — grâce à une différence de quelques centièmes de seconde qu'un ingénieur curieux a décidé d'investiguer. Ensuite, il montre qu'une attaque peut viser la confiance humaine plutôt qu'une faiblesse technique, et se dérouler patiemment sur deux ans.

La leçon 4 dépasse le cadre technique. Une part importante de l'infrastructure logicielle mondiale repose sur des projets maintenus bénévolement par une ou deux personnes. Le financement de ces mainteneurs est devenu un sujet de sécurité collective, pas une question de générosité.

5. Les 14 questions les plus fréquentes​

1. Par où commencer si je n'ai rien du tout ?

Dans cet ordre précis, du plus rentable au moins rentable :

  1. Détection de secrets avec un crochet local avant validation. Quinze minutes. Empêche la fuite la plus banale.
  2. Détection de dépendances vulnérables (Dependabot, Renovate ou équivalent). Quinze minutes. Couvre le vecteur d'attaque numéro un.
  3. Versionner le fichier de verrouillage et utiliser la commande stricte en CI.
  4. Vérifier vos images de conteneurs : utilisateur non root, image de base minimale.
  5. Analyse d'infrastructure as code si vous utilisez Terraform ou Kubernetes.
  6. SAST en dernier — c'est le plus bruyant, gardez-le pour quand le reste est en place.

Ne commencez pas par acheter une plateforme. Commencez par les points 1 et 2, aujourd'hui.

2. Combien de temps ai-je pour appliquer un correctif critique ?

Les délais couramment retenus dans les politiques d'entreprise :

  • Critique et activement exploité (présent dans la liste CISA KEV) : 24 à 48 heures.
  • Critique : 7 jours.
  • Élevé : 30 jours.
  • Moyen : 90 jours.
  • Faible : au prochain cycle de maintenance.

Le point important n'est pas le chiffre exact, c'est d'en avoir un et de le mesurer. Equifax n'avait pas de délai suivi. Si vous ne savez pas combien de temps vous mettez, la réponse est probablement trop longtemps.

3. Comment convaincre ma direction d'investir en sécurité ?

Ne parlez pas de vulnérabilités, parlez de risque commercial :

  • Le coût d'une fuite : sanctions réglementaires (jusqu'à 4 % du chiffre d'affaires sous RGPD), notification, communication de crise.
  • Les affaires perdues : chaque questionnaire de sécurité en appel d'offres demande si vous avez subi un incident.
  • Le coût comparé : une détection automatique de dépendances vulnérables est gratuite ou quasi gratuite.

L'argument le plus efficace : présentez le cas Equifax. Une faille connue, un correctif disponible depuis deux mois, et des centaines de millions de dollars de conséquences. Puis demandez : « combien de temps mettons-nous, nous ? ».

4. La sécurité va-t-elle ralentir mes livraisons ?

Mal faite, oui. Bien faite, non — et elle peut même les accélérer.

Ce qui ralentit : un audit manuel de trois semaines, et un outil qui remonte 4 000 alertes.

Ce qui ne ralentit pas : une analyse de trente secondes dans le pipeline qui bloque uniquement sur le critique et exploitable.

Ce qui accélère : les études sur les pratiques DevOps montrent régulièrement que les équipes les plus performantes en livraison sont aussi les plus performantes en sécurité. La raison est simple : automatiser les contrôles supprime les validations manuelles qui bloquaient tout.

5. J'ai poussé une clé d'API dans Git. Que faire ?

Dans cet ordre, immédiatement :

  1. Révoquez la clé chez le fournisseur. C'est l'étape indispensable, tout le reste est secondaire.
  2. Générez une nouvelle clé et placez-la dans un gestionnaire de secrets, pas dans le code.
  3. Vérifiez les journaux d'accès du fournisseur pour détecter un usage suspect.
  4. Nettoyez l'historique si vous le souhaitez, mais sans jamais considérer que cela remplace la révocation.
  5. Installez un crochet local de détection de secrets pour éviter la récidive.

Ne perdez pas de temps à nettoyer l'historique avant d'avoir révoqué. Sur un dépôt public, chaque minute compte.

6. Faut-il faire des tests d'intrusion ?

Oui, mais pas en premier. Un test d'intrusion coûte plusieurs milliers d'euros et prend une à deux semaines. Le faire avant d'avoir mis en place les bases revient à payer très cher pour apprendre que vous avez des dépendances vulnérables — ce qu'un outil gratuit vous aurait dit en quinze minutes.

Le bon moment : quand vos contrôles automatiques sont en place et propres. Le test d'intrusion trouve alors ce que l'automatisation ne peut pas voir — les failles de logique métier, les enchaînements d'exploitation, les défauts de conception.

À savoir : un test d'intrusion devient souvent une exigence contractuelle dès que vous vendez à de grandes entreprises ou au secteur public.

7. Comment sécuriser un cluster Kubernetes ?

Les points essentiels, par ordre d'importance :

  • RBAC restrictif — pas de rôle d'administration de cluster attribué largement.
  • Contexte de sécurité des pods — utilisateur non root, système de fichiers en lecture seule, pas d'élévation de privilèges.
  • Politiques réseau — par défaut, dans Kubernetes, tous les pods peuvent se parler. C'est presque toujours indésirable.
  • Secrets — les secrets Kubernetes ne sont pas chiffrés par défaut, seulement encodés. Activez le chiffrement au repos ou utilisez un coffre externe.
  • Contrôleur d'admission — refuser les images non signées ou les configurations non conformes.
  • Isolation par espace de noms avec des quotas de ressources.

Le point sur les politiques réseau surprend beaucoup de monde : Kubernetes est ouvert par défaut. Voir notre cours Kubernetes.

8. Le code généré par IA est-il un risque de sécurité ?

C'est un sujet réel et récent. Trois points à considérer :

  • Les modèles ont été entraînés sur du code public, y compris du code vulnérable. Ils reproduisent donc parfois des motifs dangereux, notamment des requêtes SQL construites par concaténation.
  • Le code généré paraît correct, ce qui réduit la vigilance en relecture. Un code qui semble propre est moins relu qu'un code manifestement bancal.
  • Les modèles peuvent suggérer des dépendances inexistantes, que des attaquants publient ensuite sous ce nom exact — une variante du typosquatting.

La bonne pratique : traitez le code généré exactement comme le code d'un stagiaire compétent mais inexpérimenté. Relisez-le, et laissez vos analyses automatiques faire leur travail dessus.

9. Quelle différence entre vulnérabilité, exploit et menace ?
  • Vulnérabilité — une faiblesse dans un système. Exemple : une requête SQL construite par concaténation.
  • Exploit — le moyen technique concret d'utiliser cette faiblesse. Exemple : la chaîne de caractères précise qui déclenche l'injection.
  • Menace — l'acteur susceptible d'agir. Exemple : un groupe criminel automatisant l'exploitation.
  • Risque — la combinaison des trois, pondérée par l'impact. C'est le seul qui compte pour prioriser.

L'usage pratique : une vulnérabilité sans exploit disponible et sans exposition représente un risque faible. Une vulnérabilité moins grave mais activement exploitée sur un service public représente un risque élevé.

10. Qu'est-ce qu'un modèle de menace, et comment en faire un ?

C'est un exercice de réflexion structuré, de deux heures, en début de projet. Quatre questions suffisent :

  1. Qu'est-ce qu'on construit ? Un schéma simple des composants et des flux de données.
  2. Qu'est-ce qui peut mal tourner ? La méthode STRIDE aide : usurpation d'identité, altération, répudiation, divulgation d'information, déni de service, élévation de privilège.
  3. Qu'est-ce qu'on fait à ce sujet ? Les mesures pour les risques retenus.
  4. A-t-on bien travaillé ? Une revue après mise en œuvre.

C'est l'activité de sécurité la plus rentable qui existe, parce qu'elle intervient avant qu'une seule ligne de code ne soit écrite. Elle ne nécessite aucun outil.

11. Quels métiers et quels salaires en sécurité ?

Les métiers principaux :

  • Ingénieur DevSecOps — automatise la sécurité dans les pipelines.
  • Ingénieur sécurité applicative — spécialisé dans la sécurité du code et des applications.
  • Testeur d'intrusion (pentester) — cherche activement les failles.
  • Analyste en centre opérationnel de sécurité — détecte et répond aux incidents.
  • Architecte sécurité — conçoit les modèles de sécurité en amont.

Ordres de grandeur en France, très variables selon la région et le secteur :

  • Débutant : entre 35 000 et 45 000 euros brut annuels.
  • Confirmé (3 à 5 ans) : entre 50 000 et 70 000 euros.
  • Senior ou spécialisé : au-delà de 75 000 euros, notamment en région parisienne, en conseil et en finance.

Le domaine est structurellement en pénurie de candidats, ce qui joue en faveur des profils qui se forment.

12. Faut-il une certification en sécurité ?

Utile, mais après l'expérience pratique. Les plus reconnues :

  • CompTIA Security+ — bon point d'entrée généraliste.
  • CEH — orientée test d'intrusion, très visible en recrutement.
  • OSCP — exigeante et très respectée pour le test d'intrusion, purement pratique.
  • CISSP — orientée management, demande cinq ans d'expérience.
  • Certifications sécurité des fournisseurs cloud (AWS, Azure, Google) — très demandées actuellement.

Le conseil réaliste : un projet personnel démontrable — un pipeline avec analyses automatiques, secrets gérés proprement, images durcies — convainc souvent davantage qu'une certification en entretien technique.

13. Comment se former à la sécurité offensive légalement ?

Ne testez jamais un système qui ne vous appartient pas sans autorisation écrite. C'est un délit, même sans intention de nuire, même sans dommage causé.

Les plateformes d'apprentissage légales et conçues pour cela :

  • TryHackMe — très progressif, idéal pour débuter.
  • Hack The Box — plus exigeant, orienté défi.
  • PortSwigger Web Security Academy — gratuit, excellent, spécialisé web.
  • OWASP Juice Shop — une application volontairement vulnérable à installer chez vous.
  • Programmes de recherche de failles (bug bounty) — cadre légal explicite, avec un périmètre défini.

Comprendre l'attaque rend bien meilleur en défense, à condition de le faire dans un cadre légal.

14. Par où commencer concrètement demain matin ?

Plan sur cinq jours, applicable à un vrai projet :

  1. Jour 1 — Installez un crochet local de détection de secrets sur votre dépôt principal. Puis analysez l'historique complet une fois. Vous trouverez probablement quelque chose.
  2. Jour 2 — Activez la détection automatique de dépendances vulnérables. Regardez le rapport, corrigez les critiques.
  3. Jour 3 — Vérifiez vos images de conteneurs : utilisateur non root, image de base minimale, aucun secret dans les couches.
  4. Jour 4 — Ajoutez une analyse SCA dans votre pipeline, en mode signalement seul pour commencer.
  5. Jour 5 — Faites un modèle de menace de deux heures sur votre fonctionnalité la plus sensible.

Semaine suivante : rendez bloquant ce qui est propre, et générez un SBOM à chaque construction.

Le principe : chaque jour apporte un bénéfice réel. Ne planifiez pas six mois de chantier.

6. Ce que vous avez appris dans ce cours​

7. Votre prochaine étape​

Piste 1 · Compléter votre culture technique​

Piste 2 · Passer à la pratique​

Piste 3 · S'entraîner légalement​

  • PortSwigger Web Security Academy — gratuit et excellent
  • OWASP Juice Shop — une application volontairement vulnérable
  • TryHackMe — parcours progressif pour débutants

8. Un dernier conseil​

Faites la chose la plus simple, aujourd'hui.

N'attendez pas d'avoir un budget sécurité, ni un expert dans l'équipe. Installez, cette semaine, une détection de secrets avant validation et une détection de dépendances vulnérables. Trente minutes de travail au total, gratuit.

Ces deux mesures couvrent les deux causes d'incident les plus fréquentes du métier : le secret qui fuite et la bibliothèque non corrigée. C'est la majorité du risque réel, pour presque rien.

Le reste — SBOM, signatures, modèles de menace, tests d'intrusion — viendra ensuite, une brique à la fois.

Retenir en 30 secondes​

  • Equifax : faille connue, correctif disponible depuis deux mois, 140 millions de personnes touchées. Problème de processus.
  • SolarWinds : la chaîne de construction compromise. Le code source était propre, le binaire piégé. La signature garantit l'origine, pas l'intégrité du processus.
  • Log4Shell : score CVSS de 10,0. Les organisations avec un SBOM ont répondu en minutes, les autres en semaines.
  • Un bon pipeline CI/CD est une capacité de sécurité — pendant Log4Shell, la vitesse de correction a dépendu de la maturité de livraison.
  • Backdoor xz : deux ans de patience, découverte par hasard. La confiance humaine est un vecteur d'attaque.
  • Le financement des mainteneurs de composants critiques est un enjeu de sécurité collective.
  • Secret poussé dans Git : révoquez d'abord, nettoyez ensuite. Ne perdez pas de temps.
  • Le code généré par IA reproduit des motifs vulnérables et paraît correct — donc il est moins relu.
  • Le modèle de menace est l'activité de sécurité la plus rentable : deux heures, aucun outil.
  • Ne testez jamais un système qui ne vous appartient pas sans autorisation écrite.
  • Commencez par deux choses : détection de secrets et détection de dépendances vulnérables. Trente minutes, gratuit, couvre la majorité du risque réel.

Merci d'avoir suivi ce cours découverte DevSecOps ! 🎉

Envie de continuer ? Retour à la table des matières ou passer au cours Premium Security DevOps.

Dernière étape : passez le quiz de fin de cours — cinq questions corrigées et expliquées, trois minutes, pour vérifier que l'essentiel est acquis.