google
Project owners need some way to mark bugs as false positives
It's pretty frequent that OSS-Fuzz infrastructure changes cause false positives (see https://github.com/google/oss-fuzz/issues/11881). This historically hasn't been a big deal, because we can just ignore them.
However, since then, these false positives are now automatically imported into OSV. As a result, the false positives will cause a ton of busywork in downstream systems until an incredibly manual process can withdraw them: https://github.com/google/oss-fuzz-vulns/pull/37
As a result, ignoring false positives is no longer viable. Project owners need to have some mechanism to mark bugs as false positives.
I think it would be great if this whole process was improved. When CVEs were assigned (semi?) automatically based on OSV data I kind of started withdrawing entires like https://github.com/google/oss-fuzz-vulns/pull/35 and https://github.com/google/oss-fuzz-vulns/pull/25 but then stopped because CVEs were seemingly gone and the other OSV consumers like scorecard with their "vulnerabilities" don't matter to me.
To make sure everyone is on the same page here, false positives here doesn't mean there was a subjective disagreement over whether an issue had security consequences. False positives here means the issue did not exist. OSS-Fuzz has false positives all the time when the compiler infrastructure needed to check for uninitialized memory, or other errors, broke. Most recently, it looks like the instrumented C/C++ runtime did not get picked up, so it mistakenly believed all strings were uninitialized.
A user of the project could not apply a fix for this issue, because there is nothing to fix.