I would turn taint checking on, and then see if the module runs. In my experience, if the module is developed without taint checking, chances are it won't pass when you add the check. Even experienced programmers often miss something. Check for the idioms that are used to untaint variables and protect IFS, etc.

If it passes, then someone probably developed with taint checking and turned it off for the shipping code. Some people feel that taint checking causes a performance hit. I have heard that any performance hit is very small, but others may not know this, or I may have bad info. When I heard the claim that the performance hit is 1-2% or less, many in the audience were surprised.

In my opinion, if the module fails the taint check then it is likely insecure. You might even be able to find an exploit of such a hole, perhaps a simple one that just lists the contents of a directory.

One of the benefits to using CGI.pm is that it does a lot of advanced things and it works well with taint checking.

Another benefit to using CPAN modules is that, in general, you have access to the developers of the code. Try calling up the vendor and ask to talk to the developer of the module. Ask the developer your same CPAN and taint questions. If you can't get relatively easy access to the developer, you have another valid reason to prefer a CPAN approach.

I have often argued that the support of perl modules is vastly superior to commercial software because of developer support and quick fixes. Commercial software bug fixes often languish is a release cycle that takes six months or more. I would ask how quickly they could get you a version that has taint checking. Chances are they would charge a hefty fee for this, or they won't be in business very long. The commercial software business is tough :-).

It should work perfectly the first time! - toma