Where I work security is a huge issue. What I've resolved must be done before CPAN modules can be used in this enviornment is to create an internal CPAN. Which will allow for several things:

1.) Keep track of who has what versions of which modules on what systems. This has several benefits; Internal points of contact for module usage, Back tracking should a security problem be discovered, revision history, and disaster recovery.

2.) Allows for new CPAN releases to 'cook' out in the world without forcing established applications to run on a new module version just because CPAN has released an upgrade and they moved to a new server.

3.) Centralizes perl user's and distribution, which provides internal avenues for problem resolution that is missing from the accepted practices of this organization. (Who does production call when a perl problem arises?)

I'm not paranoid about CPAN, but I view it as an I.V. from which a large organization must design it's own needle. What you say about code review is very true, and no matter how important security is, the type of code review you speak of is impractical. But like Perl, it's capriciousness cannot be left completely unchecked except at ones own level of acceptable risk.