Les bases du test en boîte blanche : repérer les risques de sécurité tôt dans le cycle de développement logiciel

En matière de sécurité logicielle, 85 % des utilisateurs estiment qu’elle relève de la responsabilité des personnes les plus proches du code : les développeurs et les ingénieurs. Ce n’est pas surprenant, puisque la plupart des vulnérabilités apparaissent tôt dans le cycle de vie du développement logiciel, avant même le déploiement en production. Pour une personne qui ne connaît pas de l’intérieur les systèmes ou les logiciels testés, nombre de ces vulnérabilités peuvent aussi être très difficiles à détecter.

C’est là que le test en boîte blanche entre en jeu. Dans cet article, nous allons explorer cette méthode de test de sécurité des applications, expliquer comment la mettre en œuvre, et en présenter les avantages et les inconvénients.

Explication du test en boîte blanche

Diagramme de test en boîte blanche

La principale caractéristique du test en boîte blanche est sa nature « transparente » ; on l’appelle donc aussi test en boîte de verre, en boîte claire, en boîte transparente ou en boîte ouverte. Comme le testeur ou l’outil connaît le fonctionnement interne du logiciel et sait ce que le code est censé faire, il est possible d’évaluer sa sécurité en examinant sa résistance aux attaques.

Le test en boîte blanche est l’opposé du test en boîte noire. Comme son nom l’indique, dans un test en boîte noire, le testeur de sécurité n’a pas accès au logiciel ni aux réseaux et ne sait donc que peu de choses, voire rien, sur la cible. Le testeur d’intrusion évalue l’application pour en détecter les vulnérabilités, comme le ferait un attaquant externe.

L’objectif du test en boîte blanche

Pourquoi tester un logiciel en boîte blanche ? Pourquoi cette méthode est-elle importante ? Pour deux raisons :

1. Elle permet de repérer les risques de sécurité.

Selon le rapport sur l’état de la sécurité des applications cloud-native, plus de 56 % des utilisateurs ont été confrontés à un incident impliquant une mauvaise configuration ou une vulnérabilité connue non corrigée dans leurs applications cloud-native. La sécurité des applications est essentielle, et la négliger peut avoir des conséquences désastreuses. La détection rapide des failles de sécurité permet d’éliminer les risques et d’éviter le coût élevé des incidents de sécurité, qui peuvent entamer la confiance des clients dans votre capacité à protéger leurs données, voire entraîner des poursuites judiciaires.

De nombreuses vulnérabilités de sécurité, comme la désérialisation non sécurisée, les mauvaises configurations, l’exposition de secrets et les failles de contrôle d’accès, résultent d’erreurs de programmation dans le code. Sans test en boîte blanche, il est difficile de remédier aux risques qu’elles présentent.

2. Elle permet de repérer les bugs et d’améliorer la qualité.

Les équipes logicielles travaillent en mode agile et publient fréquemment des mises à jour en fonction des retours des utilisateurs et de l’évolution des marchés. Ces mises à jour et modifications ne doivent pas compromettre les fonctionnalités existantes. Rien n’agace davantage les utilisateurs qu’une mise à jour qui perturbe des fonctionnalités existantes qu’ils apprécient. Le test en boîte blanche est essentiel pour détecter rapidement les bugs et les régressions dans les logiciels.

En résumé, le test en boîte blanche est essentiel pour détecter tôt les bugs, les failles de sécurité potentielles et les problèmes de performance.

Types de tests en boîte blanche

Il existe de nombreux types de tests en boîte blanche :

• Tests d’exécution/unitaires : ce type de test en boîte blanche consiste à exécuter une partie du code et à comparer le résultat obtenu au résultat attendu. Si le résultat attendu n’est pas obtenu, cela signifie qu’un défaut doit être corrigé. Les tests d’exécution sont effectués en continu.

• Tests statiques/analyse structurelle : cette méthode consiste à analyser soigneusement une base de code pour y repérer des bugs et des vulnérabilités, sans exécuter le code. Par exemple, un testeur peut analyser une base de code à l’aide d’outils de test statique de la sécurité des applications (SAST) pour détecter les vulnérabilités. Avec le SAST, l’application fait l’objet d’une analyse approfondie fondée sur des éléments spécifiques, comme l’analyse de configuration, l’analyse sémantique et l’analyse du flux de données, afin de sécuriser le code source.

• Tests de mutation : ils sont généralement réalisés lors de la dernière étape. Ils comprennent une vérification générale des bugs ainsi qu’une analyse permettant de déterminer les stratégies de programmation optimales pour faire évoluer le programme.

Que permet-il de tester ?

Pour effectuer un test en boîte blanche, vous devez d’abord comprendre le logiciel testé, connaître son code et le comportement attendu. Vous devez ensuite créer des cas de test en écrivant du code supplémentaire afin de vérifier les risques d’erreur lors de l’exécution et les possibilités d’exploitation des vulnérabilités.

En général, le test en boîte blanche porte sur :

• Les failles de sécurité internes

• Le cheminement de données d’entrée spécifiques dans le code

• Les résultats attendus et inattendus

• Les chemins d’exécution défectueux ou mal structurés

• La logique d’une boucle conditionnelle

• Le comportement de chacune des fonctions et classes

• La manière dont le logiciel traite des données d’entrée spécifiques

Techniques de test en boîte blanche

Le test d’intrusion en boîte blanche est une étape essentielle des tests de sécurité, car il permet d’analyser en profondeur les vulnérabilités internes et externes. La collaboration entre les testeurs de sécurité et les développeurs favorise une compréhension approfondie du système et des façons dont il pourrait être exploité. Par exemple, une technique de test en boîte blanche peut consister à vérifier la sécurité et la fiabilité d’une application bancaire et à s’assurer que sa logique métier ne comporte aucune faille.

Les techniques couramment utilisées pour les tests en boîte blanche comprennent :

• Couverture des conditions : technique servant à tester les variables d’une sous-expression au moyen de conditions logiques.

• Couverture des instructions : cette technique consiste à exécuter une série de tests sur les instructions du code ; on parle souvent de couverture des lignes. Chaque instruction est testée au moins une fois.

• Couverture des branches : les testeurs utilisent cette technique pour s’assurer que chaque branche du code est testée au moins une fois.

• Couverture des chemins : cette technique est généralement utilisée pour tester chaque chemin d’exécution d’une application.

• Test du flux de données : cette technique sert à examiner la circulation des données dans un logiciel en tenant compte des variables du code.

Test en boîte blanche et test en boîte noire

Les tests en boîte blanche et en boîte noire sont des méthodes de détection des défauts logiciels. Bien qu’il s’agisse dans les deux cas de techniques de test courantes, elles sont très différentes. Le tableau ci-dessous présente leurs principales distinctions.

Diagramme de test en boîte noire

Les tests en boîte blanche et en boîte noire ne sont donc pas interchangeables. Il ne suffit pas de réaliser l’un ou l’autre. Au contraire, ces deux techniques se complètent pour contribuer à la qualité des logiciels. Lorsque les techniques de test en boîte blanche et en boîte noire sont combinées, on parle de test en boîte grise.

Avantages et inconvénients du test en boîte blanche

Le test en boîte blanche présente des avantages et des inconvénients.

Avantages :

• Le testeur connaît déjà le système testé, ce qui réduit considérablement le temps nécessaire pour recueillir des informations ou effectuer une reconnaissance.

• Les tests sont plus approfondis et permettent de découvrir davantage de risques de sécurité qu’avec toute autre technique de test.

• Cette technique peut être intégrée aux pipelines CI à l’aide d’outils de sécurité automatisés tels que SonarQube, grâce à son approche de bas niveau.

• Cette technique étant plus proche du code, les développeurs peuvent facilement corriger les vulnérabilités détectées.

Inconvénients :

• En raison de son exhaustivité, c’est la technique de test la plus longue et la plus coûteuse.

• Elle nécessite une connaissance approfondie du système testé.

Conclusion

De par sa nature même, le test en boîte blanche est essentiel à l’adoption de la culture DevOps dans le cycle de développement logiciel sécurisé. Comme les tests en boîte blanche peuvent être automatisés, ils sont généralement exécutés dans les pipelines CI afin de fournir rapidement des retours aux développeurs lorsqu’ils vérifient leur code.

Les outils de test de sécurité en boîte blanche comme Snyk Code intègrent le test statique de sécurité des applications au pipeline DevSecOps et offrent aux développeurs la couverture de test maximale nécessaire pour repérer les risques de sécurité suffisamment tôt dans le processus de développement.