The out-of-box security of Rust is something that was discussed recently. The conclusion was that, while rustc has some strong security guarantees, Cargo remains an area with much scope to pull common mitigations in as standard.
I can point to one discussion on the matter, mostly focused on identifying the first steps (test/validate/evaluate the TUF model and use RustSec tools as linked in this thread):
The current state of Rust crates from a security standpoint (the state is quite good):
I'm currently spending an hour or two every now and then incorporating Cuckoo malware sandbox into a fuzzing/feature checking system to identify direct code injections from malicious actors. The idea is to merge later with:
The unsafe code guidelines need to have a dichotomy: Performance and Safe Performance. I'm hoping to get some C/C++ -like guidelines on security included there, both from extensive publications and from people with code auditing experience:
It's early days for Rust on the security front. I'd suggest asking yourself how much effort you'd be able to get people to put into 'trimming the lawn' so to speak. Meaning, try to sell people on the productivity enhancements of Rust, and then convince them to contribute to fixing up the security even more. As you would know, not having security on by default and out-of-the-box is about equivalent to not having that security features at all. RustBelt is doing a lot on the compiler security proofs side:
https://plv.mpi-sws.org/rustbelt/popl18/
Unfortunately, academic security proof means zip-all if it's not applied by everyone (on by default), as any red-teaming white hat hacker has discovered with much glee. And easy-to-use default security is still some way off on Rust based on initial crates security audits.