Bugs that survive the heat of continuous fuzzing

* GStreamer discovered 29 new vulnerabilities in December 2024.
* GStreamer has only two active fuzzers and a code coverage of around 19%.
* OpenSSL has 139 fuzzers.
* bzip2 reports a code coverage of 93.03%.
* Poppler includes 16 fuzzers and has code coverage of around 60%.
* Poppler relies on external dependencies like freetype, cairo, and libpng, which may not be instrumented by libFuzzer.
* DjVuLibre, a dependency used by Evince and Papers but not covered by OSS-Fuzz, was cited as the source of a critical vulnerability in Poppler.
* Exiv2 was enrolled in OSS-Fuzz for over three years, reporting vulnerabilities like CVE-2024-39695.
* The focus of fuzzing on decoding logic often leaves encoding logic vulnerable to undiscovered bugs.
* A potential vulnerability in Poppler involved a reference-count overflow that required 12 hours to trigger.

The narrative suggests that the success of large-scale automated security initiatives like OSS-Fuzz is undermined by systemic human and methodological gaps rather than being a complete solution. The primary tension lies between the scalability of automated testing and the necessity of deep, context-aware human intuition to manage complex software ecosystems. The demonstration that bugs survive continuous fuzzing in mature projects points to a failure mode where coverage metrics become a false sense of security, particularly when dependencies or execution paths outside typical testing regimes are involved. This suggests an underlying pattern of systemic oversight decay, where the incentive structure favors tracking easily measurable metrics (like basic code coverage) over the complex, emergent properties of program state and data flow. The proposed five-step workflow—incorporating value coverage and context-sensitive tracking—is a necessary corrective mechanism against this limitation by forcing the fuzzing process to confront execution semantics rather than just path existence. The difficulty in finding "extra time" bugs highlights a structural blind spot where performance constraints inherently exclude certain types of exploitation, shifting the burden toward hybrid methodologies like symbolic testing or manual review for edge cases that defy temporal constraints.
Bridge Questions: If human oversight is required to compensate for gaps, what mechanisms can be established to scale this necessary expertise beyond individual researchers to support broader OSS-Fuzz projects? How can the incentives within open-source communities be reconfigured to prioritize deeper, value-based coverage over superficial path coverage? What are the long-term implications if automated systems remain optimized solely around speed and immediate coverage rather than addressing temporal and semantic complexity?