Yes, and I hope You go all the way to the linux kernel...
Scratch that, you better break into intel and audit their microcode personally.
Anything less is just being irresponsible about your dependencies...
There are companies that are doing this. Oxide Computer is one of them. Their customers are going to thank them when it turns out the Equation Group has a backdoor in Intel's BMC.
Our code is open source, so you can choose to independently verify that if you desire.
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.
It's not really that simple, because you can only choose your imports one level deep. All of the options for 'taking responsibility' add a lot of ongoing busy work in pinning versions, reviewing code, watching for CVEs, etc. A lot of it can be avoided with improvements like the article's.
Why can you _only_ choose your imports one level deep?
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.
If you can't afford to do that work, you can't afford to depend on those libraries. If you can't afford feature X without depending on a library, then you can't afford feature X.
Except that a huge chunk of the Rust language sits in crates on the Internet that nobody is willing to sign and vouch.
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.
What are you suggesting exactly? Should I manually audit the hundreds of thousands of third party code that my project uses? That's clearly not feasible.
Right, and because you haven't done that you have no idea how insecure your code is. Tough luck if someone breaks your code via some dependency you didn't audit - you get blamed.
