I agree. This seems to be a hard problem, and broader than Perl's CPAN. PyPI, RubyGems, and Npm, for example, all face similar problems:

• Malicious modules made it into official PyPI repository
• Backdoored Ruby gems stole credentials, injected cryptomining code
• NPM blog on malicious modules
• Typosquatting package managers blog

• OT. Malicious software in PyPI by parv (2021) (Update)
• Malicious module on CPAN by choroba (2020) (Update)
• sometimes no Perl news is good news by zentara (2021) (Update)

• CPAN clients exposed to sig-related vulnerabilities by hippo (2021) (Update)
• Signature Verification Vulnerabilities in CPAN.pm, cpanminus and CPAN::Checksums - Hackeriet blog (Update)
• Addressing CPAN vulnerabilities related to checksums - blog by Neil Bowers (Update)
• Re^7: Meaning of XS object version (Package Manager Security References - example building Perl securely from source) by me (2023) (Update)

It might be interesting to compare (and learn from) the security approaches taken by each of these similar mature open source repositories.

Update (2023)

> I'm not (yet) making heavy use of cpan or cpanm tools, and I'm still getting used to them

In case it helps, a detailed example of installing modules from CPAN securely on Linux, using cpan and cpanm, can now be found here.

Thanks to your question, I now keep a long list of Security References (don't want to disappoint the LanX ;-):

• Re: Security techniques every programmer should know (Security References)