BACKGROUND: Software engineers must be vigilant in preventing and correcting vulnerabilities and other critical bugs. In servicing this need, numerous tools and techniques have been developed to assist developers. Fuzzers, by autonomously generating inputs to test programs, promise to save time by detecting memory corruption, input handling, exception cases, and other issues. AIMS: The goal of this work is to empower developers to prioritize their quality assurance by analyzing the history of bugs generated by OSS-Fuzz. Specifically, we examined what has happened when a project adopts fuzzing as a quality assurance practice by measuring bug lifespans, learning opportunities, and bug types. METHOD: We analyzed 44,102 reported issues made public by OSS-Fuzz prior to March 12, 2022. We traced the Git commit ranges reported by repeated fuzz testing to the source code repositories to identify how long fuzzing bugs remained in the system, who fixes these bugs, and what types of problems fuzzers historically have found. We identified the bug-contributing commits to estimate when the bug containing code was introduced, and measure the timeline from introduction to detection to fix. RESULTS: We found that bugs detected in OSS-Fuzz have a median lifespan of 324 days, but that bugs, once detected, only remain unaddressed for a median of 2 days. Further, we found that of the 8,099 issues for which a source committing author can be identified, less than half (45.9%) of issues were fixed by the same author that introduced the bug. CONCLUSIONS: The results show that fuzzing can be used to makes a positive impact on a project that takes advantage in terms of their ability to address bugs in a time frame conducive to fixing mistakes prior to a product release.

翻译：背景：软件工程师必须时刻保持警惕，预防并修复漏洞及其他关键缺陷。为满足这一需求，业界已开发出众多工具和技术来辅助开发者。模糊测试器通过自主生成输入来测试程序，有望通过检测内存损坏、输入处理错误、异常情况等问题来节省时间。目的：本研究的目的是通过分析OSS-Fuzz生成的缺陷历史，帮助开发者优先安排质量保障工作。具体而言，我们通过测量缺陷生命周期、学习机会及缺陷类型，探究项目采用模糊测试作为质量保障实践后发生的变化。方法：我们分析了2022年3月12日前OSS-Fuzz公开的44,102个已报告问题。通过追踪重复模糊测试报告的Git提交范围至源代码仓库，我们确定了模糊测试发现的缺陷在系统中存留的时间、修复者身份以及历史上模糊测试发现的问题类型。我们识别了引入缺陷的提交记录，用以估算包含缺陷的代码被引入的时间，并测量从引入到检测再到修复的时间线。结果：我们发现OSS-Fuzz检测到的缺陷中位存留时间为324天，但缺陷一旦被检测到，仅需中位2天即可得到处理。此外，在可识别源代码提交作者的8,099个问题中，仅有不到一半（45.9%）的缺陷是由引入该缺陷的同一作者修复的。结论：研究结果表明，采用模糊测试的项目若能有效利用其优势，即可在产品发布前及时修复缺陷，从而对项目产生积极影响。