Récemment Google a dévoilé via un article de blog le projet ClusterFuzzLite, qui permet d'organiser des tests de fuzzing de code pour la détection précoce des vulnérabilités potentielles dans la phase d'exploitation des systèmes d'intégration continue.
Actuellement, ClusterFuzz peut être utilisé pour automatiser les tests fuzz des demandes d'extraction dans les actions GitHub, Google Cloud Build et Prow, mais on s'attend à ce qu'à l'avenir, il soit compatible avec d'autres systèmes IC. Le projet repose sur la plateforme ClusterFuzz, créée pour coordonner le travail des clusters de test de fuzzing, et est distribué sous la licence Apache 2.0.
Il convient de noter qu'après l'introduction par Google du service OSS-Fuzz en 2016, plus de 500 grands projets open source ont été acceptés dans le programme de test de fuzzing continu. À partir des contrôles effectués, plus de 6.500 21.000 vulnérabilités confirmées ont été éliminées et plus de XNUMX XNUMX erreurs ont été corrigées.
À propos de ClusterFuzzLite
ClusterFuzzLite continue de développer des mécanismes de test de fuzz avec la capacité d'identifier les problèmes plus tôt dans la phase d'examen par les pairs des changements proposés. ClusterFuzzLite a déjà été introduit dans les processus de révision des modifications dans les projets systemd et curl, et il a permis d'identifier les erreurs qui n'ont pas été détectées dans les analyseurs statiques et les linters qui ont été utilisés dans la phase initiale de vérification du nouveau code.
Aujourd'hui, nous sommes heureux d'annoncer ClusterFuzzLite, une solution de fuzzing continue qui s'exécute dans le cadre des workflows CI/CD pour trouver les vulnérabilités plus rapidement que jamais. Avec seulement quelques lignes de code, les utilisateurs de GitHub peuvent intégrer ClusterFuzzLite dans leur flux de travail et fuzz pull request pour détecter les bogues avant qu'ils ne soient commis, améliorant ainsi la sécurité globale de la chaîne d'approvisionnement logicielle.
Depuis son lancement en 2016, plus de 500 projets open source critiques ont été intégrés au programme OSS-Fuzz de Google, entraînant la correction de plus de 6.500 21.000 vulnérabilités et XNUMX XNUMX bugs fonctionnels. ClusterFuzzLite va de pair avec OSS-Fuzz, détectant les erreurs de régression beaucoup plus tôt dans le processus de développement.
ClusterFuzzLite prend en charge la validation de projet en C, C++, Java (et d'autres langages basés sur JVM), Go, Python, Rust et Swift. Les tests de fuzzing sont réalisés à l'aide du moteur LibFuzzer. Les outils AddressSanitizer, MemorySanitizer et UBSan (UndefinedBehaviorSanitizer) peuvent également être appelés pour détecter les erreurs et anomalies de mémoire.
Des fonctionnalités clés ClusterFuzzLite met en évidence par exemple le vérification rapide des changements proposés pour trouver des erreurs dans l'étape précédant l'acceptation du code, ainsi que le téléchargement de rapports sur les conditions d'occurrence des plantages, la capacité de se déplacer vers tests de fuzzing plus avancés pour identifier les erreurs plus profondes qui ne sont pas apparues après vérification du changement de code, ainsi que la génération de rapports de couverture pour évaluer la couverture du code pendant les tests et l'architecture modulaire qui vous permet de choisir la fonctionnalité requise.
Les grands projets, y compris systemd et curlya, utilisent ClusterFuzzLite lors de la revue de code, avec des résultats positifs. Selon Daniel Stenberg, auteur de curl, « Lorsque les examinateurs humains sont d'accord et ont approuvé le code et que leurs analyseurs de code statiques et leurs linters ne peuvent plus détecter de problèmes, le fuzzing est ce qui vous amène au prochain niveau de maturité et de robustesse du code. OSS-Fuzz et ClusterFuzzLite nous aident à maintenir curl comme un projet de qualité, toute la journée, tous les jours et à chaque engagement.
Nous devons nous rappeler que les tests de fuzzing génèrent un flux de toutes sortes de combinaisons aléatoires de données d'entrée proches des données réelles (par exemple, des pages html avec des paramètres de balise aléatoires, des fichiers ou des images avec des en-têtes anormaux, etc.) et corrigent les éventuels échecs du processus.
Si une séquence échoue ou ne correspond pas à la réponse attendue, ce comportement indique très probablement un bogue ou une vulnérabilité.
Enfin si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant.