Google har introduceret ClusterFuzzLite-projektet, som giver dig mulighed for at organisere fuzzing-testning af kode til tidlig opdagelse af potentielle sårbarheder i forbindelse med kontinuerlige integrationssystemer. I øjeblikket kan ClusterFuzz bruges til at automatisere fuzzing-testning af pull-anmodninger i GitHub Actions, Google Cloud Build og Prow, men der forventes understøttelse af andre CI-systemer i fremtiden. Projektet er baseret på ClusterFuzz-platformen, der er oprettet for at koordinere arbejdet med fuzzing-testning af klynger, og distribueres under Apache 2.0-licensen.
Det bemærkes, at efter Googles introduktion af OSS-Fuzz-tjenesten i 2016 blev mere end 500 vigtige open source-projekter accepteret i det kontinuerlige fuzzing-testprogram. Baseret på de udførte kontroller blev mere end 6500 bekræftede sårbarheder elimineret, og mere end 21 tusind fejl blev rettet. ClusterFuzzLite fortsætter med at udvikle fuzzing-testmekanismer med evnen til at opdage problemer tidligere i gennemgangen af foreslåede ændringer. ClusterFuzzLite er allerede implementeret i ændringsgennemgangsprocesserne i systemd- og curl-projekterne og har gjort det muligt at identificere fejl, der overses af statiske analysatorer og linters, der blev brugt i den indledende fase af kontrollen af ny kode.
ClusterFuzzLite understøtter kontrol af projekter i C, C++, Java (og andre JVM-baserede sprog), Go, Python, Rust og Swift. Fuzzing-testning udføres ved hjælp af LibFuzzer-motoren. Værktøjerne AddressSanitizer, MemorySanitizer og UBSan (UndefinedBehaviorSanitizer) kan også kaldes for at detektere hukommelsesfejl og anomalier.
Nøglefunktioner i ClusterFuzzLite: hurtig test af foreslåede ændringer for at finde fejl, før koden accepteres; indlæsning af rapporter om nedbrudsforhold; muligheden for at gå over til mere avanceret fuzzing-testning for at identificere dybere fejl, der ikke dukkede op efter kontrol af kodeændringen; generering af dækningsrapporter for at vurdere kodedækningen under test; modulær arkitektur, der giver dig mulighed for at vælge den nødvendige funktionalitet.
Lad os huske på, at fuzzing-testning involverer generering af en strøm af alle mulige tilfældige kombinationer af inputdata, der er tæt på virkelige data (f.eks. HTML-sider med tilfældige tagparametre, arkiver eller billeder med unormale headere osv.) og registrering af mulige fejl under deres behandling. Hvis en sekvens fører til et nedbrud eller ikke svarer til den forventede reaktion, er det meget sandsynligt, at en sådan adfærd indikerer en fejl eller sårbarhed.
Kilde: opennet.ru
