Google introducerade ClusterFuzzLite fuzzing testsystem

Google har introducerat ClusterFuzzLite-projektet, som gör det möjligt att organisera otydlig testning av kod för tidig upptäckt av potentiella sårbarheter under driften av kontinuerliga integrationssystem. För närvarande kan ClusterFuzz användas för att automatisera fuzz-testning av pull-förfrågningar i GitHub Actions, Google Cloud Build och Prow, men stöd för andra CI-system förväntas i framtiden. Projektet är baserat på ClusterFuzz-plattformen, skapad för att koordinera arbetet med att fuzza testkluster, och distribueras under Apache 2.0-licensen.

Det noteras att efter att Google introducerade OSS-Fuzz-tjänsten 2016, accepterades mer än 500 viktiga projekt med öppen källkod i det kontinuerliga fuzzing-testprogrammet. Baserat på utförda tester eliminerades mer än 6500 21 bekräftade sårbarheter och mer än XNUMX tusen fel korrigerades. ClusterFuzzLite fortsätter att utveckla otydliga testmekanismer med förmågan att identifiera problem tidigare i granskningsstadiet av föreslagna ändringar. ClusterFuzzLite har redan implementerats i förändringsgranskningsprocesserna i systemd- och curl-projekten och gjort det möjligt att identifiera fel som missats av statiska analysatorer och linters som används i det inledande skedet av kontroll av ny kod.

ClusterFuzzLite stöder projektgranskning i C, C++, Java (och andra JVM-baserade språk), Go, Python, Rust och Swift. Fuzzing-testning utförs med LibFuzzer-motorn. Verktygen AddressSanitizer, MemorySanitizer och UBSan (UndefinedBehaviorSanitizer) kan också anropas för att identifiera minnesfel och anomalier.

Nyckelfunktioner i ClusterFuzzLite: snabb kontroll av föreslagna ändringar för att hitta fel innan koden accepteras; nedladdning av rapporter om kraschförhållanden; möjligheten att gå vidare till mer avancerad fuzzing-testning för att identifiera djupare fel som inte dykt upp efter att ha kontrollerat kodändringarna; generering av täckningsrapporter för att bedöma kodtäckning under testning; modulär arkitektur som låter dig välja önskad funktionalitet.

Låt oss komma ihåg att otydlig testning innebär att generera en ström av alla typer av slumpmässiga kombinationer av indata som ligger nära verkliga data (till exempel html-sidor med slumpmässiga taggparametrar, arkiv eller bilder med onormala titlar, etc.), och inspelning av ev. misslyckanden i processen deras bearbetning. Om en sekvens kraschar eller inte stämmer överens med det förväntade svaret, är det mycket troligt att detta beteende indikerar en bugg eller sårbarhet.

Källa: opennet.ru

Lägg en kommentar