I don’t have confidence that people are looking for evidence of potential exploitation because of reasons like the ones you bring up.
So we’re back to we just don’t know.
Its especially difficult because most projects aren't built in a reproducible way. You should be able to uncompress and compare a source tarball. But if you get a binary and the source code used to generated that binary, there's no way to tell that they match.
It's still not trivial because there might well be legitimate processing steps that are used to create the tarball, but it should be doable.
A large class of exploitation methods simply have no performance impact.
The reason Jia Tan could do their thing is because 1) the main meat was in a binary test file, 2) the code to use that seemed relatively harmless at a glance, and 3) people were encouraged to use the .tar.gz files instead of git clone. Also you need to actual get maintainer status, which is not as easy as it sounds.
I've been thinking of inserting a "// THIS LINE IS MALICIOUS, PLEASE REPORT IF YOU SEE IT" in some of my projects to see how long it would take. I bet it would be pretty fast either after commit or after tagging a release.
// this line is an external audit test - a free gift card to the first person to report finding it.Tools that use LLMs to review code will catch such projects.