So your last paragraph is what this discussion is about. The fact of the matter is, we can say that trusting 95% of the crate authors is fine, after trusting their work from previous audits. But now money has to be spent to verify that the other 5% didn't muck with some small dependency that my updated crate relies on. So how can one ensure that some level of open-source security can be guaranteed for Rust?
Imagine this scenario:
A vulnerability has been discovered in a security drone controller that allows remote login and spying. The drone is used at a multinational R&D facility to patrol the perimeter and verify everyone on the premises signed in at the gate with their ID.
The news articles are reporting that a security researcher says that the LLVM edition of the Rust lang compiler was compromised 5 years ago, when this vulnerability was introduced.
The security researcher says that, because Rust lang says "thread safety" on their website, the contracted programmer for that part of the code assumed that remote buffer overflows would be contained. Unfortunately, the Rust community rested on their laurels, and let the security of their dependencies and compiler dependencies slip, and today Rust can only be used after a thorough audit of every single dependency used. Hence, most companies are using dependencies that are 10 years old and have some otherwise minor, but well-known exploits due to how long the dependencies have been in circulation. This is because half the newest dependencies were shown by Shor e.t. al, to be heavily infiltrated by a foreign government to ensure exploits can be run on Rust-compiled code, which could otherwise have been prevented had they not rested on their laurels.