Компанията Google представи проекта ClusterFuzzLite, който позволява организиране на fuzzing-тестиране на кода за ранно откриване на потенциални уязвимости по време на работа на системите за непрекъсната интеграция. В момента ClusterFuzz може да се използва за автоматизация на fuzzing-тестиране на pull-заявки в GitHub Actions, в Google Cloud Build и в Prow, но в бъдеще се очаква поддръжка и за други CI-системи. Проектът е базиран на платформата ClusterFuzz, създадена за координиране на работата на клъстери за fuzzing-тестиране и се разпространява под лицензия Apache 2.0.
Отбелязва се, че след внедряването през 2016 година на услугата OSS-Fuzz от компанията Google в програмата за непрекъснато fuzzing-тестиране бяха приети над 500 важни открити проекта. На базата на проведените проверки бяха отстранени над 6500 потвърдени уязвимости и коригирани повече от 21 хиляди грешки. ClusterFuzzLite продължава развитието на механизмите за fuzzing-тестиране с възможност за по-ранно откриване на проблеми на етап преглед на предлаганите промени. ClusterFuzzLite вече е внедрен в процесите на преглед на промените в проектите systemd и curl, и е позволил откриването на грешки, пропуснати от статичните анализатори и линтерите, използвани на началния етап на проверка на новия код.
ClusterFuzzLite поддържа проверка на проекти на языците C, C++, Java (и други езици на базата на JVM), Go, Python, Rust и Swift. Fuzzing-тестиране се провежда с използването на енджин LibFuzzer. За откриване на грешки в работата с паметта и аномалии също могат да се извикват инструментите AddressSanitizer, MemorySanitizer и UBSan (UndefinedBehaviorSanitizer).
Основни възможности на ClusterFuzzLite: бърза проверка на предлаганите промени за намиране на грешки на етапа преди приемане на кода; качване на отчети за условията на възникване на сривове; възможност за преминаване към по-разширено fuzzing-тестиране за откриване на по-дълбоки грешки, не изплували след проверка на промяната на кода; генериране на coverage-отчети за оценка на покритие на кода при тестване; модулна архитектура, позволяваща избор на необходимата функционалност.
Напомняме, че при fuzzing-тестиране се генерират потоци от всякакви случайни комбинации от входни данни, близки до реалните данни (например, html страници с произволни параметри на тагове, архиви или изображения с аномални заглавия и т.н.), и се записват възможни сривове в процеса на тяхната обработка. Ако някаква последователност води до срив или не отговаря на очакваната реакция, то такова поведение с висока вероятност показва грешка или уязвимост.
Източник: opennet.ru
