Yup, for sure. But part of risk management is considering how likely a failure mode might be and if it's really worth paying to mitigate. Developers are really good at imagining failure modes, but often not so good at estimating their likelihood/cost.

I have no "hard rules" on how to appraise a dependency. In addition to the above, I also like to skim the issue tracker, skim code for a moment to get a feel for quality, skim the docs, etc. I think that being able to quickly skim a project and get a feel for quality, as well as knowing when to dig deeper and how deep to dig are what makes someone a seasoned developer.

And beware of anyone who has opinions on right vs. wrong without knowing anything about your project and it's risk appetite. There's a whole range between "I'm making a microwave website" and "I'm making software that operates MRIs."

Of course. A malware-infected dependency has motivation to pay for GitHub stars and fake repo activity. I would never trust any metric that measures public "user activity". It can all be bought by bad actors.

Then what do you do instead?

Would totally depend on the project and what kinds of risks were appropriate to take given the nature of the project. But as a general principal, for all kinds of development: "Bringing in a new dependency should be A Big Deal." Whether you are writing a toy project or space flight avionics, you should not bring in unknown code casually. The level of vetting required will depend on the project, but you have to vet it.

Skim through the code? Sure it's likely to miss something, but it still catches low-effort and if enough people do it someone will see it.