There was recently a fiasco with NPM over a malicious node package whose name was an intentional typo of a popular package, and upon installation it exfiltrated all environment variables: https://twitter.com/o_cee/status/892306836199800836

After this got uncovered, Duo published a blog post where they scanned for and found several others malicious packages:

https://duo.com/blog/hunting-malicious-npm-packages

The last one they talk about worms itself by adding itself to any packages authored on the computer it's installed on.

These issues are not unique to npm.

Why go out of the way when you can just buy a popular one, this was a fairly mild version of that: https://forum.sublimetext.com/t/rfc-default-package-control-...

Granted that was just data collection, but the outcome could be incredibly worse if a combo of popular but bad code and a little bit of money.

Well an existing gem might not. But a gem you use has could have a developer's computer get compromised and could publish a malicious update. If you inadvertently download it while updating your gems you could get compromised.

The problem here is that you don't even have to get directly attacked to be affected.

Well it's a web of trust: typically people only trust their Gemfile, not their entire Gemfile.lock. If you audit the latter you should be fine (though of course you should upgrade regardless).

How much do you trust the code review process on every ruby gem?