Google heeft het ClusterFuzzLite-project geïntroduceerd, waarmee fuzzing-tests van code kunnen worden georganiseerd voor vroegtijdige detectie van potentiële kwetsbaarheden tijdens de werking van continue integratiesystemen. Momenteel kan ClusterFuzz worden gebruikt om fuzz-tests van pull-aanvragen in GitHub Actions, Google Cloud Build en Prow te automatiseren, maar in de toekomst wordt ondersteuning voor andere CI-systemen verwacht. Het project is gebaseerd op het ClusterFuzz-platform, gemaakt om het werk van fuzzing-testclusters te coördineren, en wordt gedistribueerd onder de Apache 2.0-licentie.
Opgemerkt wordt dat nadat Google de OSS-Fuzz-service in 2016 introduceerde, meer dan 500 belangrijke open source-projecten werden geaccepteerd in het continue fuzzing-testprogramma. Op basis van de uitgevoerde tests zijn ruim 6500 bevestigde kwetsbaarheden geëlimineerd en ruim 21 duizend fouten gecorrigeerd. ClusterFuzzLite blijft fuzzing-testmechanismen ontwikkelen met de mogelijkheid om problemen eerder te identificeren in de beoordelingsfase van voorgestelde wijzigingen. ClusterFuzzLite is al geïmplementeerd in de wijzigingsbeoordelingsprocessen in de systemd- en curl-projecten, en heeft het mogelijk gemaakt om fouten te identificeren die zijn gemist door statische analysers en linters die worden gebruikt in de eerste fase van het controleren van nieuwe code.
ClusterFuzzLite ondersteunt projectbeoordeling in C, C++, Java (en andere op JVM gebaseerde talen), Go, Python, Rust en Swift. Fuzzing-tests worden uitgevoerd met behulp van de LibFuzzer-engine. De tools AddressSanitizer, MemorySanitizer en UBSan (UndefinedBehaviorSanitizer) kunnen ook worden aangeroepen om geheugenfouten en afwijkingen te identificeren.
Belangrijkste kenmerken van ClusterFuzzLite: snelle controle van voorgestelde wijzigingen om fouten te vinden voordat de code wordt geaccepteerd; downloaden van rapporten over crashomstandigheden; de mogelijkheid om over te gaan naar meer geavanceerde fuzzing-tests om diepere fouten te identificeren die niet aan het licht kwamen na het controleren van de codewijzigingen; het genereren van dekkingsrapporten om de codedekking tijdens het testen te beoordelen; modulaire architectuur waarmee u de gewenste functionaliteit kunt selecteren.
Laten we niet vergeten dat fuzzing-testen het genereren van een stroom van allerlei willekeurige combinaties van invoergegevens inhoudt die dicht bij echte gegevens liggen (bijvoorbeeld HTML-pagina's met willekeurige tagparameters, archieven of afbeeldingen met afwijkende titels, enz.), en dat opname mogelijk is fouten in het proces van de verwerking ervan. Als een reeks crasht of niet overeenkomt met de verwachte reactie, duidt dit gedrag zeer waarschijnlijk op een bug of kwetsbaarheid.
Bron: opennet.ru