It's definitely a lot better in memory safe languages (and especially in those applications that don't depend on C libraries under the hood). You can still have security bugs due to logic errors, but you won't ever get remote code execution or ability to read arbitrary memory. And in general bugs are much more likely to cause a crash rather than give the attacker access.
I suspect once C has been supplanted all the way down the stack it might actually be feasible to eliminate these kind of vulnerabilities entirely for apps where security is of utmost importance.
It is true that memory-safe languages are a massive massive massive boon! I believe that the entire industry needs to be making plans to find a way to shift all applications that operate on untrusted data away from C and C++. But this is completely orthogonal to the purported security benefits of making your source available.
IMO it’s not entirely orthogonal. One of the main benefits (from a security perspective) of open sourcing your app is to allow it to be audited more thoroughly. But even with that kind of auditing it’s hard to make thing secure in non memory safe languages. If you have both, then we might expect open sourcing to more reliably lead to an actually secure app.
I don't understand. Is the idea that memory errors are too hard to find but that once we've eliminated them at the language level that now auditors can review OSS projects effectively to verify that they are free of vulns? log4j should be a very clear example of how that'll fall over.
I suspect once C has been supplanted all the way down the stack it might actually be feasible to eliminate these kind of vulnerabilities entirely for apps where security is of utmost importance.