О Fuzzing-тестировании

1 Июля мейтейнер curl Daniel Stenberg написал в личном блоге о результатах использования фаззинга в течении 5 лет с помощью OSS-Fuzz. curl был добавлен в гугловскую фаззинг-ферму одним из первых и в последствии улучшен энтузиастом Max Dymond. Изначально это был одиночный фаззер и затем разросся до отдельного проекта для тестирования надежности curl.

Даниел приводит отличное описание фаззинга после его многолетнего использования - это некст-левел для проектов, когда компиляторы уже не показывают предупреждения (да, такое бывает), а статические анализаторы показывают 0. Так как найденные ошибки фаззингом часто пропускаются при статическом анализе и труднозаметны во время ревью кода.

Если изначально OSS-Fuzz направлен на непрерывный фаззинг, то в 2020 Google представили CIFuzz, цель которого на каждый PR (commit?) проводить фаззинг-тестирование ограниченное время. К примеру, в случае гитхаб это максимум 6 часов. Хотя я бы советовал не меньше 2-3 дня при технической возможности. Такой подход позволил разработчикам устранить много неприятных багов в мастер ветке проекта, а после нескольких лет использования количество уведомлений об ошибках становится меньше и меньше.

www.tgoop.com/fuzzing_life/11

225 viewsedited  Sep 5, 2022 at 13:37

1 Июля мейтейнер curl Daniel Stenberg написал в личном блоге о результатах использования фаззинга в течении 5 лет с помощью OSS-Fuzz. curl был добавлен в гугловскую фаззинг-ферму одним из первых и в последствии улучшен энтузиастом Max Dymond. Изначально это был одиночный фаззер и затем разросся до отдельного проекта для тестирования надежности curl.

Даниел приводит отличное описание фаззинга после его многолетнего использования - это некст-левел для проектов, когда компиляторы уже не показывают предупреждения (да, такое бывает), а статические анализаторы показывают 0. Так как найденные ошибки фаззингом часто пропускаются при статическом анализе и труднозаметны во время ревью кода.

Если изначально OSS-Fuzz направлен на непрерывный фаззинг, то в 2020 Google представили CIFuzz, цель которого на каждый PR (commit?) проводить фаззинг-тестирование ограниченное время. К примеру, в случае гитхаб это максимум 6 часов. Хотя я бы советовал не меньше 2-3 дня при технической возможности. Такой подход позволил разработчикам устранить много неприятных багов в мастер ветке проекта, а после нескольких лет использования количество уведомлений об ошибках становится меньше и меньше.

BY О Fuzzing-тестировании