I can't remember the name of the projects but a "bad guy" befriended the guy who looked after a small bit of code that happened to be a down stream dependency of a crypto wallet.
After helpfully contributing code and back and forth friendly chat, the maintainer gave the bad guy commit access.
In this case there isn’t a lot you can do. If a bad actor is going to spend a lot of time gaining your trust and doing good before they do bad how do you vet that? You either have to maintain full control forever or you have accept this possibility. The OP does mention that this might be a bad idea if your project has any level of security.
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.
Most project dependencies management process is flawed.
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.
I somewhat agree on principle, but at the same time, it is hard enough keeping ur software patched and up to date already, adding more friction to that process may cause more damage than it prevents.
You might prevent malicious new code at the cost of running old vulnerable code longer.
> The Pull Request Hack probably isn't suitable if you're running big projects. And it is almost certainly a stupid idea if you write code which is actively used by multiple downstream projects. And if your stuff has even the slightest chance of compromising security then you're better off sticking to trusted members.
The code (event-stream, a popular NPM package which was targeted because it's used by a crypto wallet) fails all 3 criteria.
Only one... It is really tiny and has nothing to do with security. (As in, not directly... Actually everything can impact security if it's used wrong so that point is moot).
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.
Edit here it is: https://www.theserverside.com/feature/Recent-open-source-fla...