Google har introdusert ClusterFuzzLite-prosjektet, som gjør det mulig å organisere fuzzing-testing av kode for tidlig oppdagelse av potensielle sårbarheter under drift av kontinuerlige integrasjonssystemer. Foreløpig kan ClusterFuzz brukes til å automatisere fuzz-testing av pull-forespørsler i GitHub Actions, Google Cloud Build og Prow, men støtte for andre CI-systemer forventes i fremtiden. Prosjektet er basert på ClusterFuzz-plattformen, opprettet for å koordinere arbeidet med fuzzing testing clusters, og distribueres under Apache 2.0-lisensen.
Det bemerkes at etter at Google introduserte OSS-Fuzz-tjenesten i 2016, ble mer enn 500 viktige åpen kildekode-prosjekter akseptert i det kontinuerlige fuzzing-testprogrammet. Basert på testene som ble utført, ble mer enn 6500 bekreftede sårbarheter eliminert og mer enn 21 tusen feil ble rettet. ClusterFuzzLite fortsetter å utvikle uklare testmekanismer med evnen til å identifisere problemer tidligere på gjennomgangsstadiet av foreslåtte endringer. ClusterFuzzLite har allerede blitt implementert i endringsgjennomgangsprosessene i systemd- og curl-prosjektene, og har gjort det mulig å identifisere feil som er savnet av statiske analysatorer og linters brukt i den innledende fasen av å sjekke ny kode.
ClusterFuzzLite støtter prosjektgjennomgang i C, C++, Java (og andre JVM-baserte språk), Go, Python, Rust og Swift. Fuzzing-testing utføres ved hjelp av LibFuzzer-motoren. Verktøyene AddressSanitizer, MemorySanitizer og UBSan (UndefinedBehaviorSanitizer) kan også kalles for å identifisere minnefeil og anomalier.
Nøkkelfunksjoner i ClusterFuzzLite: rask sjekk av foreslåtte endringer for å finne feil før kodeaksept; nedlasting av rapporter om krasjforhold; muligheten til å gå videre til mer avansert fuzzing-testing for å identifisere dypere feil som ikke dukket opp etter å ha sjekket kodeendringene; generering av dekningsrapporter for å vurdere kodedekning under testing; modulær arkitektur som lar deg velge ønsket funksjonalitet.
La oss huske at fuzzing-testing innebærer å generere en strøm av alle slags tilfeldige kombinasjoner av inngangsdata som er nær reelle data (for eksempel html-sider med tilfeldige tag-parametere, arkiver eller bilder med unormale titler, etc.), og opptak av mulig feil i prosessen deres behandling. Hvis en sekvens krasjer eller ikke samsvarer med forventet respons, er det høyst sannsynlig at denne oppførselen indikerer en feil eller sårbarhet.
Kilde: opennet.ru