You can’t, obviously. I know how to read code, but I still rarely do it since it’s very time consuming. Usually, if I’m nervous about something, I’ll first look at the author and see if they’re well-known, or at least tied to a real identity. In the rare cases that I have reviewed a code base (I’m not a security expert or anything) to check for malware, the things I looked for were:

• obvious red flags, like urls to fishy sites, or calls to filesystem APIs where it doesn’t make sense, paths that it shouldn’t be trying access, etc

• anything that looks obfuscated, poorly written, or delibrately designed to be difficult to read

But if it’s anything related to Node/NPM, I always use a throwaway rootless podman container without filesystem access. Even if the author is trustworthy, their dependency graph is likely a bag of used needles that they picked up on the side of the road.

Probably a simple way without looking at ANY code is to just look at a few key points on GitHub (or GitLab or other):

Stars This is the number of people who have favourited the package. In general, if a package has more stars (500+, 1000+) it is probably good and has had a lot of people looking at it and using it. Beware packages with only a few stars (fewer than 20, but context matters.)

Forks Also look at the number forks the repo has. In general, the more forks it has, the more people in the community have contributed to it, fixing bugs, tightening security, etc. Again, the more eyes the package has on it, the higher the chance that key vulnerabilities have been identified and fixed.

Number of Contributors same reason as forks.

When last the files in the repo were updated Occasionally you’ll find a package that meets the above heuristics very well, but was only last updated 5 to 10 years ago. Avoid these as they aren’t up to date and therefore have vulnerabilities.

All these points are just rough heuristics and there will be exceptions but can generally point even experienced developers in the right direction.