Edit here it is: https://www.theserverside.com/feature/Recent-open-source-fla...
One of the maxims of security is that a sufficiently determined and resourceful attacker will always win. The defender's job is to disincentivize the attacker.
However, I think for a sufficiently high-impact project no-one should have commit access, every commit should be reviewed by quorum. Even so, you still run into "Underhanded C"-style stuff (and disinterested reviewers), and you still need to vet the quorum.
We shouldn't blindly upgrade modules/deps minor or patch versions to latest with a single command. SemVer encourages this, but we should be more careful.
The software supply chain for a lot of OSS is flawed as well. We need software signatures, and less central artifact registries that can be compromised easily.
I don't have a perfect solution for all these problems. Rewriting code instead of relying on external deps, vendoring, automated vulnerability scans, higher scrutiny for all external code, and tighter processes for code management.
You might prevent malicious new code at the cost of running old vulnerable code longer.
The code (event-stream, a popular NPM package which was targeted because it's used by a crypto wallet) fails all 3 criteria.
It does have multiple downstream users. But I will bet 99% of projects where contributors submit good PRs, and maintainers have not enough time so they give commit access, have multiple downstream users.