8,5 millions d'ordinateurs plantés à cause d'un seul fichier que personne, de votre côté, n'a examiné

Un ami qui dirige la sécurité d'une compagnie aérienne de taille moyenne m'a envoyé une photo au petit-déjeuner le 19 juillet 2024. C'était un tableau des départs, sauf que chaque panneau affichait la même teinte de bleu, avec le même texte d'erreur blanc répété panneau après panneau à travers le terminal. Il n'a rien écrit avec. Il n'avait pas besoin de le faire.

Le temps que je finisse mon café, le chiffre était de 8,5 millions de machines Windows, plantées en moins de quatre-vingt-dix minutes. Pas un logiciel malveillant. Pas une faille zero-day. Une mise à jour de contenu de routine de CrowdStrike, un fournisseur que ces entreprises payaient précisément pour les protéger. La chose qui protégeait les terminaux était la chose qui les rendait inutilisables.

J'ai passé le temps écoulé depuis à construire la couche qui aurait dû se trouver entre ces fournisseurs et ces machines — ce que nous appelons désormais l'intégrité du déploiement des mises à jour logicielles, un point de contrôle indépendant entre le pipeline de mises à jour d'un fournisseur et votre parc de production. Cet essai porte sur les raisons pour lesquelles cette couche n'existait pas, pourquoi la manière évidente de la construire est erronée, et ce qui a changé sous chaque entreprise exploitant des agents au niveau du noyau à l'instant où ce tableau bleu s'est allumé.

Le 21ᵉ champ

J'ai lu l'analyse externe des causes profondes de CrowdStrike la nuit de sa publication, en août 2024, et la cause était si minime qu'elle en était presque insultante.

Falcon, le capteur de CrowdStrike, distribue sa logique de détection via un mécanisme qu'il appelle Rapid Response Content — de petites mises à jour de configuration qui lui permettent de réagir à de nouvelles menaces sans déployer un tout nouveau binaire. Le 19 juillet, il a distribué deux nouvelles Template Instances pour la détection de communication inter-processus. Ces instances référençaient un 21ᵉ paramètre d'entrée. Le Content Validator basé sur le cloud de CrowdStrike a vérifié la mise à jour par rapport au nouveau schéma à 21 champs, a constaté qu'elle était valide et l'a approuvée.

Le problème était le Content Interpreter s'exécutant à l'intérieur du noyau Windows, au Ring 0, la couche la plus privilégiée du système d'exploitation. Il attendait encore 20 champs. Lorsqu'il a tenté d'atteindre le 21ᵉ, il a lu une mémoire qui n'existait pas, et la machine a instantanément affiché un écran bleu.

Un validateur dans le cloud a approuvé une mise à jour selon les nouvelles règles. Le noyau qui l'a reçue vivait toujours selon les anciennes. Personne ne vérifiait que les deux concordaient.

Voici la partie qui me dérange encore le plus en tant qu'ingénieur. Le plantage s'est produit si tôt dans la séquence de démarrage que l'agent de gestion de Falcon lui-même ne s'est jamais lancé. Les terminaux ne pouvaient donc pas recevoir la commande de restauration que CrowdStrike a envoyée, car le logiciel censé recevoir cette commande était précisément la chose qui faisait planter la machine. L'industrie a un nom sinistre pour cela — la boucle de l'agent mort. La récupération n'était pas un bouton. C'était un humain, à chaque machine, démarrant en mode sans échec, naviguant vers C:\Windows\System32\drivers\CrowdStrike\, et supprimant le fichier C-00000291-*.sys défectueux à la main. Delta a fait cela sur 40 000 serveurs. La récupération a pris cinq jours.

Cela n'a jamais concerné un seul fournisseur

L'histoire facile est que CrowdStrike a été négligent. C'est aussi la mauvaise leçon, et la poursuivre m'aurait conduit à construire le mauvais produit.

Car le schéma n'est pas propre à CrowdStrike. Ouvrez l'inventaire des terminaux de n'importe quelle grande entreprise et vous trouverez huit à douze agents s'exécutant au niveau du noyau ou avec des privilèges élevés — l'agent EDR, un agent de prévention des pertes de données, un agent de chiffrement, un agent de correctifs, un client VPN, un agent de gestion des appareils. Huit lignes sur un tableur, et huit canaux de mise à jour distincts, chacun poussant selon son propre calendrier, chacun laissé passer sans contrôle.

J'ai continué à poser aux RSSI la même question cet été-là : qui examine ces mises à jour des fournisseurs avant qu'elles n'atteignent la production ? La réponse, à chaque fois, était une version de nous avons un comité consultatif de changement. Et puis, un instant plus tard, la partie honnête : le comité consultatif de changement examine les déploiements internes ligne par ligne, mais les mises à jour des fournisseurs contournent la file des tickets, contournent la phase de préproduction, et vont directement vers chaque terminal — parce que « nous faisons confiance au fournisseur ». Cette phrase portait tout le secteur, et elle n'avait aucun mécanisme derrière elle.

Il existe un second mode de défaillance dont presque personne ne parle, et il est pire à diagnostiquer. Lorsque deux fournisseurs mettent à jour les interfaces du noyau le même jour, leurs pilotes peuvent entrer en conflit et produire exactement le même écran bleu qu'un bogue à fournisseur unique. Sauf que maintenant l'analyse des causes profondes prend des semaines au lieu d'heures, parce que vous triangulez entre deux équipes de support fournisseur qui, chacune, raisonnablement, accusent l'autre.

La version que nous avons construite en premier, et pourquoi elle a échoué

Lorsque nous avons commencé, j'étais certain que la réponse était la détection. Surveiller les terminaux, apprendre à quoi ressemble la normalité, et hurler à l'instant où une mise à jour commence à mal se comporter. C'est l'instinct que tout le marché de l'observabilité nous a appris à avoir — Datadog, Dynatrace, Splunk, tous brillants pour vous dire ce qui vient de se passer.

Nous avons construit une version de cela. Nous l'avons exécutée sur une relecture de défaillances provoquées par des mises à jour. Et cela a fonctionné, de la manière la plus inutile possible : cela a détecté le problème à merveille, après que les premières machines soient déjà tombées en panne.

Je me souviens de l'appel où cela s'est concrétisé. Un RSSI pilote a regardé notre tableau de bord s'allumer quelques secondes après le début d'un mauvais déploiement simulé et a dit, en substance, qu'il n'avait pas besoin d'un moyen plus rapide de découvrir qu'il était déjà en feu. Il avait besoin que la mise à jour n'atteigne jamais tous ses terminaux à la fois en premier lieu. La détection après déploiement, pour une défaillance qui met quatre-vingt-dix minutes à toucher 8,5 millions de machines, est un détecteur de fumée qui sonne une fois que la maison a disparu.

L'observabilité vous dit que le bâtiment brûle. À ce moment-là, la seule question qui reste est de savoir combien de jours prendra la reconstruction.

C'est ce mois-là que j'avais discrètement misé le travail sur la mauvaise couche, et regarder ce tableau de bord le prouver a été la chose la plus utile qui nous soit arrivée. Le problème n'a jamais été la vitesse de détection. C'était qu'il n'y avait aucun point de contrôle avant que la mise à jour n'arrive.

Alors pourquoi les outils existants ne détectent-ils pas cela ?

Les gens supposent que la sécurité de la chaîne d'approvisionnement logicielle couvre déjà cela. Ce n'est pas le cas, et la raison est précise.

Les outils SBOM et d'analyse de composition logicielle — Snyk, Sonatype — auditent votre arbre de dépendances open source. Ils sont conçus pour vous dire qu'un paquet npm trois niveaux plus bas présente une vulnérabilité connue. Mais le Rapid Response Content d'un fournisseur, un fichier de canal, un blob de configuration propriétaire signé et poussé par CrowdStrike ou n'importe quel homologue — cela leur est invisible. Ce n'est pas dans votre arbre de dépendances. C'est poussé en contournant celui-ci, directement dans le noyau. Les outils censés sécuriser votre chaîne d'approvisionnement logicielle auditent entièrement la mauvaise couche.

ITIL et votre comité consultatif de changement ? Procéduraux. Ce sont des listes de contrôle et des approbations conçues pour les changements que vous initiez, et ils n'ont jamais été reliés à la cadence de publication d'un fournisseur.

Et la propre remédiation de CrowdStrike — mode d'auto-récupération, épinglage de contenu, « contrôles de déploiement client » échelonnés, un cadre Resilient-by-Design emprunté à la CISA — est un travail réel, et je ne le rejette pas. Mais lisez ce que c'est réellement : chacun de ces contrôles relève de l'autosurveillance du fournisseur. La même entreprise qui a distribué le 21ᵉ champ est celle qui certifie qu'elle est désormais sûre. Il n'y a toujours aucune partie indépendante se tenant entre la poussée du fournisseur et votre terminal. La rétention brute de CrowdStrike se situait au-dessus de 97 % le trimestre suivant la panne, ce qui vous indique que le marché ne les a pas punis — et ne vous dit rien sur la question de savoir si la faille sous-jacente s'est refermée. Ce n'est pas le cas.

Cette faille est le produit tout entier. Le bon endroit où se tenir n'est pas sur le terminal à guetter le feu, et ce n'est pas à l'intérieur du fournisseur à croire sa parole. C'est entre les deux : un point de contrôle neutre vis-à-vis des fournisseurs qui prend la mise à jour avant qu'elle n'atteigne la production, l'exécute dans un bac à sable qui reflète votre parc réel, vérifie le contenu par rapport à ce que votre noyau attend réellement, et modélise le rayon d'impact si elle est erronée. C'est la couche que nous avons fini par construire, et vous pouvez en voir la forme sur notre page de solution. Une incohérence de schéma comme le bogue des 21 champs contre 20 est exactement le genre de chose qu'un bac à sable de pré-déploiement fait remonter dans un anneau canary plutôt qu'à travers 8,5 millions de machines à la fois.

Le terrain juridique s'est déplacé, et la plupart des contrats n'ont pas suivi

Pendant un temps, j'ai traité le volet réglementaire comme un bruit de fond. J'avais tort, et les acheteurs m'ont montré pourquoi : les contrats dans leurs tiroirs ne les protègent plus de la manière dont ils le pensent.

Commençons par Delta contre CrowdStrike. En mai 2025, à la Cour supérieure du comté de Fulton, le juge Ellerbe a laissé prospérer des demandes pour négligence grave, intrusion informatique et fraude par omission — au-delà du plafond de responsabilité contractuelle de CrowdStrike. Le volet de l'intrusion informatique est celui qui devrait faire dresser l'oreille à chaque RSSI : Delta avait désactivé les mises à jour automatiques, et le fichier de canal a quand même atteint le noyau. Si un fournisseur peut pousser du contenu Ring 0 via un canal que vos paramètres ne régissent pas, les préférences de mise à jour de votre accord pourraient être inapplicables. La plupart des accords-cadres de services d'entreprise ne distinguent même pas une mise à jour complète du capteur d'un contenu de réponse rapide. Ils le devraient.

Puis l'UE a agi, et c'est la partie que je soulève désormais dans chaque renégociation de contrat à laquelle je participe. La directive révisée sur la responsabilité du fait des produits classe désormais explicitement le logiciel comme un « produit » soumis à la responsabilité sans faute, et stipule que les entreprises ne peuvent pas exclure contractuellement leur responsabilité pour les défauts logiciels et de cybersécurité. Le plafond de responsabilité de quelques millions que votre fournisseur a entouré dans le contrat pourrait tout simplement ne pas tenir dans les juridictions de l'UE. Parallèlement, le règlement européen sur la cyberrésilience impose la déclaration obligatoire des vulnérabilités à partir du 11 septembre 2026 — un compte à rebours de 24 heures qui, fait crucial, démarre lorsque vous en prenez connaissance, et non lorsque le fournisseur vous en informe. La panne d'un fournisseur peut devenir votre obligation de déclaration, et vite.

Et aux États-Unis, la SEC exige désormais que les sociétés cotées divulguent les incidents de cybersécurité importants dans un délai de quatre jours ouvrables et décrivent le risque de la chaîne d'approvisionnement logicielle dans leurs rapports 10-K. Faites le calcul avec les données de coût : l'étude New Relic de septembre 2025 a établi le coût médian d'une interruption informatique significative à 2 millions de dollars par heure, et 41 % des entreprises de taille moyenne à grande situent leur propre chiffre entre 1 et 5 millions de dollars par heure. Une panne de quatre heures due à une mise à jour d'un fournisseur que votre comité de changement n'a jamais vue franchit à elle seule le seuil de matérialité. Votre équipe des relations avec les investisseurs a besoin d'un plan d'action face aux pannes des fournisseurs, pas seulement d'un plan d'action face aux violations.

Une panne de quatre heures due à une mise à jour que personne de votre côté n'a examinée s'élève à environ 8 millions de dollars au médian — le genre de chiffre qui atterrit sur le bureau du directeur financier, pas sur celui du RSSI.

« Cela pourrait-il nous arriver ? »

Après juillet 2024, chaque conseil d'administration du monde a posé à son RSSI les mêmes quatre mots. Et les RSSI à qui j'ai parlé n'avaient pour la plupart pas de réponse structurée — ce qui n'est pas un reproche à leur égard. Les données de recherche d'IANS du début de 2026 ont révélé que seuls 29 % des administrateurs de conseils jugent le reporting de sécurité de leur RSSI « très efficace », et le risque de déploiement des mises à jour est exactement le genre de chose qui est réelle, coûteuse, et presque impossible à chiffrer avec les outils dont disposent la plupart des équipes.

C'est la moitié plus discrète de ce que nous avons construit. Non seulement le point de contrôle technique, mais aussi la chose qui transforme « cela pourrait-il nous arriver » en une réponse présentable au conseil : un inventaire de chaque agent privilégié et de son canal de mise à jour, un modèle quantifié de rayon d'impact par fournisseur, un registre des mises à jour qui ont été mises en bac à sable et de ce qu'elles y ont fait. Cela convertit une diapositive qui disait auparavant « nous faisons confiance à nos fournisseurs » en une diapositive qui montre le travail.

Les gens me demandent si cela est vraiment nécessaire maintenant que Microsoft pousse les fournisseurs de sécurité hors du noyau — l'initiative de résilience Windows, avec Quick Machine Recovery et le déplacement progressif de la sécurité des terminaux du mode noyau vers le mode utilisateur. C'est un changement structurel réellement bon, et il réduira le pire rayon d'impact au fil du temps. Mais le calendrier s'étend jusqu'en 2026 et 2027, vous passerez toute cette période à exploiter un parc mixte en pleine migration, et « moins catastrophique » n'est pas « vérifié ». Un agent en mode utilisateur qui distribue une mauvaise configuration peut toujours mettre hors service ce dont il est responsable. Le besoin d'une vérification indépendante ne disparaît pas lorsque le noyau disparaît ; il monte simplement d'une couche.

L'autre chose que les gens disent est qu'ajouter un point de contrôle ralentit tout — que tout l'intérêt du Rapid Response Content est la rapidité face aux menaces en direct. C'est juste. Mais le choix n'a jamais été la vitesse contre la sécurité. Le validateur cloud de CrowdStrike a fonctionné vite et a quand même approuvé la mise à jour défectueuse, parce qu'il a vérifié le fichier par rapport au nouveau schéma et n'a jamais vérifié que le noyau était d'accord. La vitesse n'était pas la défaillance. L'absence d'une vérification indépendante l'était. Un anneau canary qui détecte une incohérence de schéma sur 30 machines vous coûte des minutes. L'alternative a coûté à Delta cinq jours et 550 millions de dollars.

Que signifiait réellement le tableau bleu ?

Je reviens sans cesse à la photo de mon ami de ce tableau des départs. Pendant une matinée, l'abstraction à l'intérieur de laquelle vit chaque entreprise — nos fournisseurs de confiance nous protègent — a été rendue en bleu littéral, panneau après panneau, dans un bâtiment rempli de gens bloqués.

Les fournisseurs n'ont pas échoué parce qu'ils étaient imprudents. Ils ont échoué parce que nous, collectivement, avons bâti une industrie où un seul fichier de configuration d'un seul fournisseur pouvait atteindre chaque terminal à la fois sans qu'aucune partie indépendante ne vérifie les calculs. CrowdStrike a été celui dont le numéro est sorti. La structure qui l'a permis se trouve, en ce moment même, dans l'inventaire des terminaux de presque toutes les entreprises que vous pouvez nommer — huit à douze agents privilégiés, huit à douze canaux, et personne entre les deux.

Vous pouvez lire l'architecture complète du point de contrôle que nous avons construit ici. Mais la partie que je voudrais qu'un RSSI retienne est plus simple que n'importe quel produit. La prochaine panne de ce type ne s'annoncera pas comme un incident de sécurité. Elle arrivera signée, de confiance, et approuvée — exactement de la manière dont la dernière l'a fait. La seule chose qui change la fin, c'est quelqu'un se tenant entre la poussée et le parc de production, vérifiant que la mise à jour et la machine concordent encore avant que les 8,5 millions d'entre elles ne l'apprennent toutes à la fois.