Vetting the cargo

> I would also add that there is no actual reason to not trust the author of all-padding. On what ground should I do that?

This is the crux of the issue, I believe.

There is no reason to distrust a library when its maintainers are well-behaved: don’t introduce vulnerabilities themselves, don’t pull in libraries with known vulnerabilities, and depend on the libraries you trust -- note: “you”, *not* other people.

But that’s the thing: trust is good until it’s not, then it gets lost. You want to be notified of something worthy of your distrust early. When you see a CVE reported for some library, you immediately distrust that particular version. If that was a malicious change, you might want to distrust whoever did that change and whoever let it get in.

Now, how do you get CVEs reported in the first place? That’s where audits come into the picture. Someone supposedly reviews the code then either vouches that it’s good or reports these CVEs. You want to have all code from your dependencies reviews by someone -- either yourself, or someone you trust.

Tools like this formalize this “thousand eyeballs” expectations that come with depending on libraries. When you pull in dependency, you trust that someone has looked at the code and did not see any obvious malicious parts in it. Without these tools your trust in that is placed in absence of reported CVEs -- which is a bad metric: that’s akin to saying that bugs don’t exist until there is a ticket. With tools like this you’d know exactly who vetted which code and when, then you are free to establish whatever policy you want on top of that.

Naturally, the risk of getting malicious code in your build tree is still there. But there is only one way to *remove* it: never depend on any code that you did not write yourself (and even then, you can introduce vulnerabilities). All other ways are merely reducing the risk to an acceptable level.