one friend of mine is a sysadmin in a finance company, and there are policies in place explicitly forbidding the use of CPAN modules.

I hate to say it, but there is a lot of merit in that approach.

No, really, there isn't. Wherever possible, risks should be managed, not simply avoided. And CPAN is a manageable risk.

A policy that does have merit is "no unaudited CPAN modules". It makes sense to control the code coming into your systems; it makes sense to check the licenses and to perform due diligence in (for example) looking at the bug trackers, reading module reviews, looking over the code for nasty smells, and finally installing the code on a development server and checking that it isn't likely to break anything in the operational environment. And, of course, it makes sense to require people to present a good business case before you allocate the resources to do all that work.

It does not make sense to automatically reject all third-party code. You will waste time and money reinventing wheels. Has that place seriously even written their own versions of stuff like DBI?! If so, they'll have ended up with something that probably contains more bugs, performs worse, and behaves differently from the standard interface that everyone else in the world uses. And to this day they'll be wasting even more time and money maintaining it themselves, instead of letting other people take care of that while they put all their resources into doing their core business well. This is not the path of merit.