We have attempted to minimize binary blobs to a pretty extreme extent. Unfortunately there are a couple of things from vendors that are impossible to remove, but we have made progress on avoiding as many of them that are avoidable as possible. bcantrill did a talk about this (and some other things) https://news.ycombinator.com/item?id=32911048 if you're curious.
That said your overall point that you’re always trusting somebody is absolutely valid.
With rust at least, don't just pull crates off crates.io. Use a locally managed registry and only allow crates you've mirrored to be pulled. If that crate has a dependency then you need to pull that dep as well. It seems like a lot of work (because it is) but this is how you validate supply chains.
I'm honestly a bit upset that years before Log4shell I never tried to make a software repackaging company. At least within the DoD sphere being able to source libraries / software from a US vender is a big plus. I think enough that I could've basically just provided Review as a Service where I "sell" OSS software as a US Company and then use that money to review & develop those OSS software.
Proc macros pull in a bunch of dependencies that pretty much exist in every single Rust program. Serde might as well be in the Rust language as the Orphan Rule prevents anything else from being anywhere near as effective now that it has momentum. Those entire trees of dependencies should be signed and vouched by Rust itself as they are effectively part of the language. And, yet, they aren't.
Rust has enough adoption at this point that they should probably switch to something like Maven's repository where you have to have domain control and a PGP key to release things. It would also solve the problem of namespace squatters.