Project owners need some way to mark bugs as false positives

[davidben]

It's pretty frequent that OSS-Fuzz infrastructure changes cause false positives (see #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: google/oss-fuzz-vulns#37

As a result, ignoring false positives is no longer viable. Project owners need to have some mechanism to mark bugs as false positives.

[davidben]

A related issue: #6974

[evverx]

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 google/oss-fuzz-vulns#35 and google/oss-fuzz-vulns#25 but then stopped because CVEs were seemingly gone and the other OSV consumers like scorecard with their "vulnerabilities" don't matter to me.

[davidben]

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.