Discussion: signal/noise ratio too low?

From the rkyv maintainer:

I think the advisory database has a signal-to-noise ratio that is too low. While there are many legitimate advisories, there are also plenty of advisories that are just pedestrian bugs without a specific impact on security. If codebases have an "attention budget" for preventing vulnerability exploitation, advisories act like a heuristic for where to allocate that attention. The bar for moving that attention to specific issues should be relatively high because we already have good general-purpose heuristics to follow. Using this issue as an example:

• The threat model is not well-defined. An attacker would have to be able to OOM a process as this specific subroutine is being executed. OOM-ing before would most likely cause the process to safely panic, and rkyv itself does not provide any kind of mechanism for causing an OOM.

• The actual outcome is undefined behavior. UB can lead to a vulnerability alone, but it's a very broad class of errors and many of them do not have that kind of potential. Here, a null pointer gets turned into an out pointer and written to. In most situations, that will become a segfault. rkyv doesn't guarantee panic-freedom, so just halting isn't a security issue. Obviously there's no guarantee that the compiler will actually produce code that does this, but...

• There is no proof of concept. This would be a very difficult bug to trigger even under controlled circumstances, and if you can't cause this bug even with everything going your way then I don't think it's worth bringing a lot of attention to.

Overall, I'd consider this the equivalent of a "bogus CVE" for RUSTSEC (as RUSTSEC is not a CNA and does not issue CVEs). The incentives leading to bogus CVEs are systemic, and I won't waste time fighting them when it doesn't make a difference. I take security issues seriously and I do file CVEs to notify users of serious issues when warranted so they can protect themselves. But it's not my job to keep other people's vulnerability databases clean - if RUSTSEC wants people to use and rely on their advisories then the onus is on them.

There have been a bunch of high-volume lower-quality submitters active and I've been facilitating that a little bit (mainly because reviewing advisories is volunteer work and so I'm trying to limit the amount of time spent on it).

Should we establish/document some clearer guidelines to increase the bar, especially for higher volume advisory submitters?

cc @alex @tarcieri @Shnatsel

Start with this issue's discussion and review how the advisory database currently handles the concerns described: threat models, undefined behavior, proof of concept, and lower-quality submissions. Done means producing and documenting clearer guidelines that raise the bar for advisories, especially from high-volume submitters, with agreement from the relevant maintainers.