Informations sur les tests logiciels suite à l'incident CrowdStrike

La catastrophe de CrowdStrike restera dans l'histoire comme un exemple de la manière dont une attention insuffisante portée à la qualité et aux tests logiciels nuit à l'image d'un fournisseur et à la foule des utilisateurs. Quelles que soient les causes profondes, il est juste de donner à CrowdStrike le temps d'analyser ses problèmes et de partager les résultats. Cependant, profitons de cette situation pour proposer quelques observations générales sur la qualité des logiciels.

L’équilibre entre les risques commerciaux et le coût de la qualité des logiciels

Compte tenu de la fréquence des mises à jour publiées par CrowdStrike dans son secteur de sécurité difficile, il est évident que l'automatisation de son processus de développement est excellente. Les flux de travail hautement automatisés basés sur CI/CD sont absolument essentiels dans le développement de logiciels modernes. L'intégration et la livraison continues améliorent l'efficacité des équipes logicielles et permettent le développement de logiciels à grande échelle.

Lorsque l’ensemble du processus est automatisé et instrumenté, vous pouvez consulter des chiffres et des statistiques et mieux comprendre les coûts. Lorsque vous pouvez mesurer, vous êtes tenté d’optimiser. Surtout dans un secteur confronté à une pression constante pour être lean, agile et réactif. L’équilibre entre le risque commercial et le coût de la qualité des logiciels est un problème bien connu dans l’industrie.

Les processus de test et de qualité sont de simples objectifs d’optimisation. L'optimisation signifie souvent réduire les tests. Nous ne disons pas que c’est ce qui s’est produit dans le cas CrowdStrike, mais cet esprit est visible parmi les éditeurs de logiciels. La mise en œuvre de plusieurs techniques de test demande du temps et des efforts. Il y a aussi un coût d'entretien.

Temps et coût des tests

Même si nous examinons un système moyennement complexe composé d'un frontend et d'un backend avec des microservices et de tout ce qui est implémenté en C++, Java et peut-être Python, un processus de qualité solide doit probablement inclure :

• Analyse statique pour tous les langages de programmation
• Tests unitaires
• Test d'API
• Virtualisation des services
• Tests de charge et de performances

Aussi, les couverture de code doivent être collectés à partir de tous les types de tests d’exécution. Cela représente un effort considérable à mettre en œuvre et à maintenir.

Même si elles sont déployées avec succès, les techniques de test dont la maintenance est plus coûteuse ont tendance à se dégrader avec le temps et sont abandonnées. Les équipes vérifient périodiquement les statistiques des bogues détectés par une pratique de test donnée et se demandent : cela en vaut-il la peine ?

Avec le temps, les équipes ont tendance à se concentrer sur un ou deux types de tests faciles à automatiser et à maintenir. Les coches vertes à côté des pull request créent une fausse confiance avec le temps et suppriment la réflexion sur la question de savoir si le risque est suffisamment atténué.

Il n’y a rien de révolutionnaire dans la conclusion ci-dessus. C'était toujours comme ça. Cependant, d'après nos observations, paradoxalement, avec l'augmentation des niveaux d'automatisation, la tolérance des équipes aux dépenses et aux retards liés aux tests diminue.

Une approche globale des tests axée sur la gauche

La vérité à propos des tests logiciels est qu’il n’existe pas de solution miracle. Vous ne pouvez pas tester la qualité d'un logiciel. Au lieu de cela, cela nécessite une approche holistique pour l’ensemble du SDLC qui comprend :

1. Construire un logiciel de qualité dès le départ avec un approche de test avec décalage à gauche.
2. Cultiver une stratégie de test robuste et riche pour accroître la confiance dans le code.

Il existe de nombreuses techniques de test, chacune étant efficace pour détecter une classe spécifique de problèmes. Une qualité et une fiabilité logicielle élevées exigent combinant plusieurs méthodologies de tests. La soi-disant optimisation de l’ensemble de votre processus de test pour n’inclure qu’une ou deux méthodologies est une voie aveugle.

La tentation de réduire les tests est encore plus forte lorsqu’il n’existe aucune obligation pour certaines pratiques. Pour les systèmes critiques pour la sécurité, il existe des normes dédiées qui imposent une analyse des risques et recommandent d'utiliser un ensemble de techniques de test de logiciels. Si vous souhaitez introduire un produit sur le marché, vous devez prouver qu'il est conforme à la norme.

Les normes de sécurité fonctionnelle classent généralement les fonctionnalités selon leur niveau de criticité et fournissent différents niveaux de recommandations pour des techniques de test spécifiques. Ci-dessous, vous pouvez voir un exemple de la norme ISO 26262, une norme populaire dans le secteur automobile.

Les détails de ce tableau ne sont pas importants pour notre discussion. Ce qu’il faut retenir, c’est que les normes de sécurité distinguent différents niveaux de criticité des systèmes (AD) et s’accompagnent de diverses recommandations sur la manière de tester les systèmes. Lorsque vous souhaitez ignorer une pratique de test spécifique que la norme juge appropriée pour un niveau de risque donné, vous avez besoin d'une histoire vraiment solide pour votre évaluateur.

Le processus de sécurité comprend l'analyse des dangers et l'évaluation des risques. Il s'agit d'une base pour définir des objectifs de sécurité, mettre en œuvre des fonctionnalités et effectuer des tests appropriés en fonction d'un niveau de risque défini. Sans entrer dans le jargon spécifique à l'industrie, il s'agit de définir des scénarios critiques et de s'assurer de les prévenir ou de les tester suffisamment.

Conclusion

Dans le cas de Falcon, il semblerait que tout scénario empêchant le démarrage de l’ordinateur soit critique. Il devrait y avoir des mesures de sécurité contre cela. Au minimum, des tests approfondis devraient être effectués pour le détecter. Et ces tests devraient être prioritaires.

Le développement de logiciels critiques pour la sécurité coûte extrêmement cher. Non, nous ne suggérons pas que tous les produits soient développés avec les mêmes contraintes que dans un monde où la sécurité est critique. Cela serait peu pratique et difficile à justifier d’un point de vue commercial.

Cependant, il est intéressant d'observer comment des systèmes apparemment non critiques, tels que Falcon de CrowdStrike, affectent nos vies. La perturbation des opérations de la ligne 911 met certainement en danger la santé, voire la vie de plusieurs personnes malchanceuses.

Alors, quels enseignements pour les équipes de développement ?

• Soyez conscient et résistez à la dynamique qui les pousse constamment à faire des économies et à compromettre la qualité en faveur de gains commerciaux à court terme.
• Comprendre le véritable niveau de criticité des systèmes qu'ils construisent, y compris le risque commercial pour l'organisation.
• Mieux comprendre les meilleures pratiques et processus mis en œuvre par les secteurs industriels où les produits affectent directement la vie humaine peut être un exercice utile et une source d’inspiration précieuse.

En tirant parti Solutions Parasoft C et C++ pour l'analyse statique, les tests unitaires, l'intégration continue et la surveillance, CrowdStrike aurait pu détecter et résoudre ses problèmes de mise à jour logicielle en temps réel, en maintenant l'intégrité de ses versions logicielles.

Notre équipe d'experts estime que les tests de logiciels sont une discipline d'ingénierie et que prévenir les catastrophes d'origine logicielle nécessite du temps et des efforts. Nos solutions aident les équipes à minimiser les coûts et à reprendre le contrôle des risques commerciaux. Tout type d'entreprise aux enjeux élevés peut bénéficier de notre expertise en matière d'analyseurs de code statique, de couverture de code, de cadres de tests unitaires, de tests d'API, de virtualisation de services, etc.