Fun fact: I went through non-DoS vulnerabilities in RustSec advisory DB and counted 16 memory corruption vulns and 5 vulns not related to memory safety. That's very close to the 70% vulns being memory safety issues as reported by M$. Based on this (admittedly limited) sampling it would look like Rust's safety guarantees do not actually make a difference in practice.
But if you factor in DoS then it absolutely dominates the memory safety issues: https://github.com/rust-fuzz/trophy-case lists so many DoS bugs that the actual memory safety issues are below 10%
It's not a 1:1 comparison. A lot of the Rust ones are API unsoundness, for many of them it's never been established that it's reachable in real programs. The MS data is CVEs that are all reachable in Windows/Office/Edge/etc.
If we issued CVEs for C APIs that were unsound... it's literally all of them, there is no notion of soundness.
To be clear: it's good that we're holding ourselves to a higher standard! But it does mean the data is not immediately comperable.
I guess the C version of API unsoundness would be "library function behaves differently compared to what documentation says" and would very well apply to M$ libraries or Windows syscalls
seems like a hard thing to measure/compare without it being apples to oranges. you need some way to also gauge frequency/volume of vulnerabilities (vs LoC I guess) and to accurately compare that vuln discovery and reporting needs to be equally mature.
there are a lot of people (who don't actively use Rust) who seem overly eager to latch onto any mention of memory unsafety in Rust and use that to speciously claim that Rust isn't living up to its guarantees :cry: