It doesn't seem like a crazy idea to me to have some "second tier" of packages that undergo a higher level of scrutiny and have to pass that before they are released in that tier.

Maybe an arbitrary set of security endorsements would be more flexible.

That permits retaining a low bar for just making the stuff initially-accessible in packaged format, but also helps developers in raising the floor.

Like, okay. Say I have something like:

$ cat .config/npmrc
required_security_endorsements=["npm_auto_audit", "maintainer_id_validated", "european_cybersecurity_competence_center_tier_1", "nsa_tier_1"]
$

An attempt to install a release of a package without those endorsements fails.

That's going to always create pressure to get something a security endorsement so that it can be used by people who only permit packages with some given security endorsement, but it lets parties start running security endorsement projects to improve the situation without excluding any existing projects from pushing stuff to npm.

EDIT: Also, I've not done much node.js development, but assuming that the dependencies in a package manifest default to the newest version unless specific frozen versions are mandated, a la PyPI, it might reasonably be able to fall back to versions with the required security level automatically, if they're available. If the dependency format permits specifying optional dependencies, a particular dependency could be automatically excluded to conform to the security endorsement requirements list.