Is it the largest though? Based on https://owasp.org/www-project-top-ten/, it would be part of #6 or #8. While one can always walk and chew gum at the same time (and those rewriting system software are likely not the same people who need to design systems with less flawed access control), replacing stable software is not without risk (e.g. https://lwn.net/Articles/1043103/, which is an instance of #6 caused by rust). Would you trust a rewrite of OpenSSH in rust (absent any information about its authors)?
Owasp deals with web security only. That whole area is biased towards php/ruby/js/python/beam where those issues don't exist outside of native modules.
https://www.cvedetails.com/vulnerabilities-by-types.php is a bit more clear. It's xss, SQL, then memory. The first two are not possible to enforce a fix on - you can always make a decision to do something bad with no visible annotation. Even then, rich types like in rust make safe interfaces easier to produce. But rust tackles the next class of issues - one that you can verify to be safe or require an explicit "unsafe" around it.
But how many breaches get CVEs (or are caused by them)? Given how much users (and their data) interact via the web vs any other platform, reducing the breaches of services is going to improve users lives more than reducing the number of CVEs (does mongodb defaulting to not have username/password to access have a CVE).
As for preventing XSS and SQL injections, that's what good web frameworks do. If your framework encourages you to write raw unescaped SQL, or doesn't provide sensible defaults around content policies, then no matter what language it's in, there are going to be issues (and maybe if we called these frameworks "unsafe" then we'd get somewhere with fixing them).
Pretty consistently [1] [2] [3] [4] it comes out that nearly %80 of security vulnerabilities come from memory safety vulnerabilities. I would consider that largest. Especially Microsoft's doc is pretty telling that this ratio was pretty consistent since 2006 so no amount of external tooling and training solves this. [1] https://langui.sh/2019/07/23/apple-memory-safety/ (albeit apple solving this with an another language and a really nice cpu extension) [2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-... [3] https://security.googleblog.com/2019/05/queue-hardening-enha... [4] https://x.com/LazyFishBarrel/status/1129000965741404160
In which code though? What counts as a security vulnerability (does the design of the play store such that searching for an app and the top result not being that app count)? I like everyone else want a secure browser, but my secure browser isn't going to prevent my email (or passwords) from appearing on https://haveibeenpwned.com/. I like rust, and want to write more rust, but if I were to port openssh to rust, I guarantee my rust code would have more CVEs than openssh.
My feeling is in the specific instance of using rust in apt, this is most likely a good thing (though I hope existing well tested rust libraries are used rather than NIHing them and introducing new bugs), but so far Ubuntu's rustification has not gone smoothly, so I'm more wary of the changes that e.g. improvements to Firefox via rust.
> though I hope existing well tested rust libraries are used rather than NIHing them and introducing new bugs
I think that's much more likely to introduce bugs.
Think of it that way, a lot of the Rust libraries are rewriting existing copyleft libraries in permissive licenses, so they cannot look at the original code, dooming them to repeat the mistakes that were made in the original code and having to fix them all over again on their own (as both go from "oh this is simple" to "oh another corner case").
I just want to translate code 1:1 to Rust, reusing my existing knowledge, design decisions, and tests. It should behave _exactly_ the same as before, just memory safe.
I don't agree with openssh take but yeah we don't need to migrate everything to rust and yeah a migration not always goes smoothly I am using sudo-rs on my arch install for over a year havent had any issues yet.