Vous êtes dans : Accueil > Tribunes libres >

Panne majeure CrowdStrike : petite digression sur le bug incriminé

Cédric Cartau, MARDI 30 JUILLET 2024

On en est à compter les points de qui a fait quoi, qui a codé quoi et qui a planté qui, mais depuis la panne majeure CrowdStrike on voit sur les réseaux le bout de code incriminé, supposé avoir provoqué tout ce ramdam. En gros, une erreur de manipulation de pointeur, un grand classique du bug[1]. Et chacun d’incriminer le code, donc le développeur. Ou, c’est selon, le fait que les mises à jour de différents types d’évolution du logiciel ont été faites en même temps.    

Sauf que je ne suis pas d’accord, voici pourquoi.

Un pilote d’avion, entre le moment où il tourne la clé de contact et le moment où il rentre du vol, commet entre 5 et 10 erreurs par heure – vous avez bien lu, par heure. Certaines de ces erreurs sont totalement anodines (se tromper dans la fréquence radio), d’autres plus graves mais sans conséquences, d’autres potentiellement catastrophiques. Toute la formation, tout l’entraînement des pilotes vise à réduire ce nombre, voire à mettre en place des mécanismes d’autodétection et d’autocorrection, mais même un pilote de ligne aguerri en commet et en commettra toujours un nombre irréductible : l’erreur est consubstantielle à l’action humaine.

La sécurisation d’un vol ne passe pas ou plus, à ce stade, par le pilote (si une compagnie prétend que ses pilotes ne font jamais d’erreurs, fuyez braves gens), mais par l’addition de couches successives de mécanismes de sécurité, autrement nommées barrières de Reason. L’humain évite certaines erreurs, mais en laisse passer d’autres, la technologie écarte certaines de ces erreurs résiduelles, mais en laisse aussi passer, idem pour la couche suivante (l’organisation), idem pour la couche suivante (l’équipage), puis pour la couche procédure, etc. Dit autrement, la sécurité du vol ne dépend pas du pilote, mais de tout cet écosystème.

Pour en revenir à l’incident CrowdStrike, le problème n’est pas le bug (quel développeur peut décemment prétendre coder sans bug ?), mais tout l’écosystème qui va du codage en passant par les différentes phases de test (unitaire, de régression, analyse automatisée du code, etc.), la préproduction (qui peut se décliner en plusieurs phases) et la mise en production (qui peut aussi être découpée). Ou, en termes de sécurité systémique, le problème n’est pas le bug, mais le dysfonctionnement des plaques de Reason.

Si une compagnie aérienne répond à un accident ou à un incident en prétendant améliorer la formation de ses pilotes, je n’ai pas, mais alors pas du tout confiance. Si par contre elle revoit l’ensemble de son dispositif (toutes les plaques de Reason), c’est exactement la chose à faire.

Le fait que, dans les heures qui ont suivi la panne, le top management de CrowdStrike affirmait que le langage trop permissif serait en cause et que tout allait être redéveloppé dans un langage plus robuste de type Rust démontre que, manifestement, le problème n’a pas été compris. Il serait bon qu’il étudie les causes de l’explosion de la fusée Ariane 5 en 1996 (due à un bug de dev dans un des langages pourtant réputés parmi les plus sûrs à l’époque : Ada).

Les actions menées par CrowdStrike faisant suite à l’incident planétaire vont être déterminantes pour la suite.

[1] https://users.rust-lang.org/t/was-crowdstrike-a-null-pointer-related-c-bug/114696 

L'auteur

Responsable Sécurité des systèmes d’information et correspondant Informatique et Libertés au CHU de Nantes, Cédric Cartau est également chargé de cours à l’École des hautes études en santé publique (EHESP). On lui doit aussi plusieurs ouvrages spécialisés publiés par les Presses de l’EHESP, dont La Sécurité du système d’information des établissements de santé.

#logiciel#sécurité#formation


Les plus lus