Google het die ClusterFuzzLite-projek bekendgestel, wat dit moontlik maak om fuzzing-toetsing van kode te organiseer vir vroeë opsporing van potensiële kwesbaarhede tydens die werking van deurlopende integrasiestelsels. Tans kan ClusterFuzz gebruik word om fuzz-toetsing van trekversoeke in GitHub Actions, Google Cloud Build en Prow te outomatiseer, maar ondersteuning vir ander CI-stelsels word in die toekoms verwag. Die projek is gebaseer op die ClusterFuzz-platform, geskep om die werk van fuzzing-toetsklusters te koördineer, en word onder die Apache 2.0-lisensie versprei.
Daar word opgemerk dat nadat Google die OSS-Fuzz-diens in 2016 bekend gestel het, meer as 500 belangrike oopbronprojekte in die deurlopende fuzzing-toetsprogram aanvaar is. Op grond van die toetse wat uitgevoer is, is meer as 6500 21 bevestigde kwesbaarhede uitgeskakel en meer as XNUMX duisend foute is reggestel. ClusterFuzzLite gaan voort om fuzzing toetsmeganismes te ontwikkel met die vermoë om probleme vroeër te identifiseer in die hersieningstadium van voorgestelde veranderinge. ClusterFuzzLite is reeds in die veranderingshersieningsprosesse in die systemd- en krulprojekte geïmplementeer, en het dit moontlik gemaak om foute te identifiseer wat gemis word deur statiese ontleders en linters wat in die aanvanklike stadium van die nagaan van nuwe kode gebruik word.
ClusterFuzzLite ondersteun projekhersiening in C, C++, Java (en ander JVM-gebaseerde tale), Go, Python, Rust en Swift. Fuzzing-toetsing word uitgevoer met behulp van die LibFuzzer-enjin. Die AddressSanitizer-, MemorySanitizer- en UBSan (UndefinedBehaviorSanitizer)-nutsgoed kan ook geroep word om geheuefoute en anomalieë te identifiseer.
Sleutelkenmerke van ClusterFuzzLite: vinnige kontrolering van voorgestelde veranderinge om foute te vind voor kode aanvaarding; die aflaai van verslae oor ongeluktoestande; die vermoë om oor te gaan na meer gevorderde fuzzing-toetsing om dieper foute te identifiseer wat nie na vore gekom het nadat die kodeveranderinge nagegaan is nie; generering van dekkingsverslae om kodedekking tydens toetsing te assesseer; modulêre argitektuur wat jou toelaat om die vereiste funksionaliteit te kies.
Laat ons onthou dat fuzzing-toetsing behels die generering van 'n stroom van alle soorte ewekansige kombinasies van invoerdata wat naby aan werklike data is (byvoorbeeld html-bladsye met ewekansige merkerparameters, argiewe of beelde met abnormale titels, ens.), en opname moontlik mislukkings in die proses hul verwerking. As 'n volgorde ineenstort of nie ooreenstem met die verwagte reaksie nie, sal hierdie gedrag waarskynlik 'n fout of kwesbaarheid aandui.
Bron: opennet.ru