Qu'est-ce que le test à données aléatoires ?

Les tests à données aléatoires sur les valeurs d'entrée d'une application, ou fuzzing des applications, est une technique de test logiciel qui permet aux équipes de découvrir des vulnérabilités ou des bogues de sécurité dans le code source des applications logicielles. Contrairement aux méthodologies de test logicielles traditionnelles (SAST, DAST ou IAST), il s'agit essentiellement de « stresser » le code avec des intrants aléatoires dans le but de le planter et d'identifier ainsi des défauts qui ne seraient autrement pas apparents. Ces défauts de code (ou problèmes de logique métier) représentent des domaines potentiellement à haut risque pour les menaces de sécurité.

Lorsqu'une panne ou une vulnérabilité est détectée, un fuzzer, qui est un outil identifiant les causes potentielles du plantage, peut être utilisé pour trouver des vulnérabilités spécifiques dans le code source. Les fuzzers sont plus efficaces pour découvrir les vulnérabilités qui peuvent être exploitées par des attaques telles que l'injection SQL et les attaques de cross-site scripting, où les pirates informatiques désactivent la sécurité pour voler des informations ou faire tomber un système. Les fuzzers sont moins efficaces pour identifier les vulnérabilités qui ne sont pas liées aux plantages système, telles que les logiciels espions ou les chevaux de Troie.

Les partisans des tests à données aléatoires les apprécient car ils sont entièrement automatisés et capables de trouver des faiblesses obscures, tandis que ses détracteurs se plaignent qu'ils peuvent être difficiles à configurer et enclins à fournir des résultats peu fiables.

Les tests à données aléatoires se distinguent également d'une autre manière : la façon dont le concept a été découvert. En 1988, le professeur Barton Miller de l'Université du Wisconsin à Madison essayait d'accéder au code à l'aide d'un système d'accès à distance, mais les perturbations dues à un orage provoquaient le plantage répété du programme. L'idée que le « bruit » externe ne pouvait pas être toléré par le code a inspiré le travail de Miller et de son élève. Ils ont découvert que les programmes Unix, Mac et Windows plantaient régulièrement lorsqu'ils étaient stressés par des intrants aléatoires inattendus. Miller est l'un des auteurs de Fuzzing for Software Security Testing and Quality Assurance.

Il existe deux principaux types de fuzzing : guidé par la couverture de code et comportemental.

Le fuzzing guidé par la couverture de code se concentre sur le code source pendant que l'application est en cours d'exécution, en le sondant avec un intrant aléatoire dans le but de découvrir des bogues. De nouveaux tests sont constamment générés et l'objectif est de faire planter l'application. Un plantage signifie un problème potentiel, et les données du processus de tests à données aléatoires guidé par la couverture de code permettront à un testeur de reproduire le plantage, ce qui est utile lorsqu'il essaie d'identifier le code exposé à un risque.

Le fuzzing comportemental fonctionne différemment. En utilisant des spécifications pour montrer comment une application doit fonctionner, elle utilise des intrants aléatoires pour juger de son fonctionnement réel ; la différence entre ce qui est attendu et la réalité abrite généralement des bogues ou d'autres risques de sécurité potentiels.

Pourquoi les tests à données aléatoires sont-ils importants pour DevSecOps ? En raison de la nature aléatoire du fuzzing, les experts affirment qu'il s'agit de la méthodologie la plus susceptible de détecter les bogues manqués par d'autres tests. Il est également considéré comme une méthodologie de test à incroyablement faible effort, ce que certains résument avec la formule « configurez-le et oubliez-le ». Une fois le harnais de test créé, le test à données aléatoires est entièrement automatisé et s'exécutera indéfiniment. Il peut être facilement mis à l'échelle en faisant tourner plus de machines et constitue un bon choix pour les tests de régression. Le fuzzing accélère également le processus de développement en maximisant la couverture de code, c'est-à-dire la quantité de code exécutée par le fuzzer, sans introduire de faux positifs. Une couverture de code plus élevée signifie des tests plus approfondis.

Le fuzzing est également idéal pour travailler aux côtés d'une équipe de test manuel, car les deux ensembles d'intrants serviront à une évolution mutuelle.

Les professionnels du développement qui cherchent à mettre en œuvre des tests à données aléatoires sont confrontés à deux principaux défis : la configuration et l'analyse des données. Le fuzzing n'est pas nécessairement facile à mettre en place ; il nécessite des « harnais » de test complexes qui peuvent être encore plus difficiles à créer si le fuzzing n'est pas réellement situé dans une chaîne d'outils existante. De plus, le fuzzing peut générer beaucoup de données, y compris des faux positifs potentiels. Il est donc essentiel de s'assurer qu'une équipe de test est prête à faire face à l'assaut d'informations.

En outre, bien qu'elles soient moins faciles à documenter, les attitudes négatives à l'égard de la nature « vague » du fuzzing persistent dans la communauté de l'assurance qualité.