angler-fishThe Vulnerability History Project

VHP News

June 13, 2023 ### New site design! * We've overhauled our look-and-feel throughout the site, starting with the homepage. * Now have a light mode and a dark mode! We're still ironing out any bugs, so feel free to file bugs over at [our issue tracker](https://github.com/VulnerabilityHistoryProject/vulnerability-history/issues) ---
May 15, 2023 ### What Happens When We Fuzz? Investigating OSS-Fuzz Bug History Brandon Keller presented the following publication based on the work here in VHP at the International Conference on Mining Software Repositories 2023, in Melbourne Australia. Abstract is below: 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. However, the rate at which we find authors are not correcting their own errors suggests that not all developers are benefiting from the learning opportunities provided by fuzzing feedback. DOI: 10.1109/MSR59073.2023.00038 ---
January 22, 2023 ### Our first workshop! And new Zenodo updates * We've held our first workshop, and we're in the process of testing out our process for bringing practitioners into the curation process * New Zenodo integration! Now that we've merged all of our separate vulnerabilty repos into a single place, citing us in academic literature is much easier. If you ever need to cite us, use the DOI that is generated at [this page](https://doi.org/10.5281/zenodo.7558231). * Version 7.0 of the dataset! New commit information, new Django vulnerabilities. ---
January 7, 2023 ### We have News! * Added this changelog! * Added a few previous entries to backfill several years of work ---
November 9, 2022 ### Linux Kernel! * Linux Kernel! We've incorporated 349 Linux kernel vulnerabilities, mostly from the year 2021. * Fall 2022 curation! We ran a curation project between two 30-student classes, and we've now merged the curations of 73 vulnerabilities. ---
Have a VHP-related news item you want to share? Post a pull request on our [writing repository](https://github.com/VulnerabilityHistoryProject/vhp-writing).
Go to Github
expand_less