We've recently released open-source tools that would have easily prevented this:
1. The maintainers could have used PRevent to immediately alert and block any PR containing malicious code, or easily configured it for detection in case of a direct push:
https://github.com/apiiro/PRevent
2. Users could have used our malicious code detection ruleset to immediately detect and block it when scanning updates in all relevant CI/CD stages:
https://github.com/apiiro/malicious-code-ruleset
Malicious code detection is a fools errand. The attacker would’ve known that was installed and obfuscated it to avoid detection. It’s trivial to do so because they know what the detection is.
They have no way of knowing unless they have admin access, in which case they can do whatever they want anyway. If the tool produces any visible outputs, just configure it to block silently. That's on the maintainer side. On the consumer side, not even that discloses such use. Isn't it so?
Add behavioral detection, and you get a strong layer of defense, even if attackers know about it. You still want defense in depth as always, of course.
I just went to the readme of PRevent, and looked at it when writing my comment. It puts a comment explaining specifically which code triggered the problem. The attacker can easily see this happening and then test locally with PRevent to make sure their obfuscated code will bypass your detection no?
1. The maintainers could have used PRevent to immediately alert and block any PR containing malicious code, or easily configured it for detection in case of a direct push: https://github.com/apiiro/PRevent
2. Users could have used our malicious code detection ruleset to immediately detect and block it when scanning updates in all relevant CI/CD stages: https://github.com/apiiro/malicious-code-ruleset
3. For a better understanding of the detection, the malicious code falls precisely into the patterns presented in our research: https://apiiro.com/blog/guard-your-codebase-practical-steps-...