This is an indictment of the designers of wild lands systems like ruby Gems and npm and a culture of pulling in hundreds of dependencies that simply cannot be verified by end users.
It's one thing if this was just for developers who made a conscious decision to use a gem or npm package, but the whole system is carried on to end users who are expected to have a build environment and pull in hundreds of unknown gems and packages which in turn pull in their own dependencies simply to deploy.
This is bad engineering and design, it not only dramatically increases the complexity of deployment and wastes millions of man hours in debugging, versioning and build issues but leaves end users exposed to security issues.
I do wish we'd move toward more of a system of forced MFA, GPG signed binaries, and a lot more conservatism on the part of developers before pulling in other gems. I don't think it's realistic to abandon it.
But also, assume it will happen so use some auditing and alerting capabilities to detect.
Review the code you're trusting, or at least look at who's shipping it so you know what your trusting ( random individual / reliable group ).
Scan as many dependicies you have, so you're aware of these rather than just luckily reading it on hacker news.
All this is really just the MVP.
> In the grand scheme of things, this backdoor likely has a fairly low impact. As noted, the backdoor was found and fixed quickly but, for a little while, it did have the potential to wreak havoc on affected sites. It is a popular gem, but the version that was backdoored was not from the current 3.4.x branch; 3.2.0.2, which was the last good version before the compromise, was released in September 2014.
Always a good reminder tho to use a defense-in-depth strategy. Containerize your applications and keep the image as lean as possibly so the attacker's capabilities are minimized.