De nombreuses entreprises ne sont pas encore pleinement conscientes des avantages de l'utilisation du fuzzing lors du développement de leurs logiciels. Mais la sécurité des produits doit aller de pair avec le développement. Parce que corriger ce qui a déjà été fait demande beaucoup de main-d'œuvre et beaucoup plus cher que de bien faire tout de suite.
Et cela malgré le fait que des concepts tels que Security Development Life Cycle (SDLC), et relativement récemment tels que DevSecOps ou SecDevOps, sont apparus dans le monde du développement depuis longtemps, mais tout le monde n'utilise pas ces techniques. Ils ont une essence - mettre en œuvre des approches pour améliorer la sécurité dès les premières étapes du développement, et il est préférable de commencer par la formation des employés. Et, bien sûr, il est important de faire attention à la sécurité du produit contre les attaques tout au long de son cycle de vie. Pour plus de détails - bienvenue au chat.
L'une des étapes les plus importantes d'un développement sûr est le fuzzing. Le fuzzing est une technique de test de logiciels, dont l'essence est la détection automatisée des erreurs de mise en œuvre en leur envoyant des données sciemment incorrectes et en analysant la réaction du programme.
Tout en écrivant un article sur Twitter, des notes vacillaient sur l'utilisation du fuzzing de Dmitry Vyukov.
Il attire simplement l'attention sur le fait qu'en utilisant le fuzzing, vous pouvez détecter un grand nombre d'erreurs dans le code, qui autrement ne disparaîtront pas même après un laps de temps.
Habituellement, le fuzzing complète le processus de développement, mais le fuzzing peut également séparer les fonctions du produit développé.
Avantages du fuzzing par rapport aux autres méthodes de test:
- Vous pouvez commencer à flou et l'oublier jusqu'à la fin des tests et travailler avec les résultats;
- les tests automatisés peuvent identifier les erreurs qui n'ont pas pu être trouvées par des tests manuels, en raison de la plus grande couverture du code;
- vous permet de recueillir une idée générale de la sécurité du code testé.
L'un des cas sensationnels où le fuzzing a fait son œuvre est la découverte de cinquante CVE dans Adobe Reader en 50 jours. Les chercheurs ont pu trouver autant de vulnérabilités sans accès au code source, et il est difficile d'imaginer combien d'entre elles auraient été découvertes si elles avaient eu la source.
Si vous recherchez dans les sources ouvertes des informations sur l'utilisation du fuzzing parmi les développeurs, Microsoft sera le premier. Cette entreprise est l'un des pionniers du fuzzing dans le SDLC. Ils disposent de Security Risk Detection , un service qui permet aux utilisateurs de télécharger des fichiers binaires pour leur fuzzing. Quelles données seront introduites dans l'entrée, l'utilisateur décide. Le résultat du flou est les erreurs trouvées et les données qui les ont générées.
Google utilise également le fuzzing, et ils ont tellement d' outils dans le domaine public. Le plus intéressant d'entre eux est OSS-Fuzz . Son essence est que n'importe qui peut faire une demande de pull avec son fuzzer. Ce sont généralement des fuzzers, une fois créés par les développeurs pour leurs petits projets. En plus de ces fuzzers, Google utilise ClusterFuzz pour détecter les erreurs dans Chrome. Depuis plusieurs années, plus de 16 000 vulnérabilités dans le navigateur et plus de 11 000 dans 160 projets open source ont été découverts.
Certaines entreprises qui développent des logiciels fournissent à tous des assemblages nocturnes pour le fuzzing. Mozilla et VLC aussi . Tout le monde peut télécharger l'assembly et essayer d'y rechercher des erreurs et des vulnérabilités.
Bien sûr, de nombreux développeurs de logiciels propriétaires ne disent pas comment augmenter la sécurité de leurs produits. Mais le fait que beaucoup d'entre eux ne prêtent pas l'attention voulue à la sécurité de leurs produits est évident dans le nombre de vulnérabilités détectées. Par conséquent, nous avons décidé de mener une enquête par sondage auprès des développeurs pour connaître leur attitude à l'égard du fuzzing.
Nous avons posé les questions suivantes:
Utilisez-vous le fuzzing dans votre processus de développement de produits?
Un tiers des répondants ont répondu positivement à cette question.
Sinon, pourquoi? Ou qu'est-ce qui, à votre avis, vous empêche généralement d'incorporer la phase de fuzzing dans le processus de développement du produit?
Réponses possibles:
- Rien à fuzz
- La sécurité des produits n'est pas une priorité
- Pas d'outils adaptés
- Aucun spécialiste pertinent
- Manque d'infrastructures appropriées
- Autre
Les répondants pouvaient choisir plusieurs raisons pour refuser d'utiliser le fuzzing dans le processus de développement.
Le diagramme montre le pourcentage de pertinence des raisons du refus du fuzzing dans le processus de développement.
La raison la plus courante de NE PAS utiliser le fuzzing était le manque d'employés qualifiés dans ce domaine. Mais il n'est pas toujours nécessaire d'avoir vos propres experts en sécurité de l'information, vous pouvez attirer des experts externes qui auditeront les produits développés.
Certains des répondants qui ont choisi l'option de réponse «Autre» ont donné des réponses détaillées intéressantes. Voici quelques raisons de refuser le fuzzing:
- le département de la sécurité de l'information n'a pas apprécié l'initiative d'un des développeurs d'écrire leur fuzzer;
- manque de techniques de recherche de vulnérabilités FSTEC.
Parmi les réponses figuraient des clarifications sur l'utilisation des fuzzers AFL et libfuzzer , ce qui est une bonne nouvelle .
En tant qu'experts en sécurité, nous vous conseillons de ne pas négliger le développement sécurisé, y compris l'utilisation du fuzzing, pour augmenter la sécurité de vos produits.