I read a possibly dated view by a security researcher that slowly introducing Rust into a C/C++ codebase may actually make the codebase less secure — since the C part can be made aware/can mitigate memory errors while in pure Rust, there is no such thing due to lack of need - so a buffer overflow can potentially cause bigger problems this way.
If someone with more knowledge on C and Rust compilers and security, I would be interested in their opinion on this.
> slowly introducing Rust into a C/C++ codebase may actually make the codebase less secure
I think to some extent this used to be true, and to some extent still is.
Rust didn't always have MIRI support which points out if you try to do some unsound thing. Maybe 4 years ago you would have been the first person to use a specific niche static analyzer that builds on LLVM with Rust, so there would have been bugs inevitably. Same goes for wanting to analyze both the C and Rust that call each other. So static analyzer support has improved I think.
Also, C is better understood while in Rust it's less obvious how things need to look like. With better understood I don't mean by the developers who write the code, but from a language specification point of view. E.g. views have evolved on how accessible uninitialized memory should be in unsafe Rust, so MaybeUninit has been added. It's only two years old at this point.
Also there is the issue of safe interfaces between languages. In the days before cxx, if you had a "safe" cpp smart pointer, moving it to Rust and back would have involved possibly more unsafety than operating on that smart pointer yourself.
There has also been the long standing issue of unwinding at FFI boundaries.
If you have a codebase with 5 thousand lines of cpp and now replace 1 thousand lines with a Rust component of 500 lines, it might still be a better idea to just keep the old solution and give it a thorough review. It's different I think if you have a codebase with 5 million lines of cpp though and replace one component of 50k lines that has a clean interface but is an extreme source of vulnerabilities. It's a question of how dangerous "surface" is between the two languages.
Does all of this mean you shouldn't invest into Rust? Absolutely no. If it's a 5k lines codebase, you can rewrite it completely. If it's a 5 million lines codebase, I'm sure you'll find a security bug ridden component that is well isolated that you can replace.
I'm knowledgeable on C and Rust and security and it sounds like a red herring to me.
It's unclear what they're trying to say, but a charitable interpretation would be that C code assumes unsafety, therefor mitigations are in place. But it's actually the opposite situation - rustc is generally quite aggressive about turning mitigations on, and adopts them very quickly.
If someone with more knowledge on C and Rust compilers and security, I would be interested in their opinion on this.