Security is never a “product.”   It is a process.   Therefore, no security-testing “product, alone” would have any meaning, even if you did find one.   (And of course, you can.   Snake-oil sells well.)

Having said all that, I do have a few idle thoughts about what I'd consider to be things that you should keep in mind with regard to the security of your Perl-based web site:

1. Your Perl version, and your web-site software whatever it is, should be kept up-to-date.   This allows you to keep abreast of the updates that are from time to time provided by the various software suppliers.   Keep abreast of discussions that happen right here.
2. Most intrusions into a web-site are actually “out-of-band.”   No one penetrated the defenses of the web-site:   they went around it, just as the Germans defeated the Maginot Line by rendering it obsolete.   Therefore, pay most attention to the operating-system environment, to the integrity of your shared-hosting vendor, and to thoroughly hardening your dedicated-host environment.   (For example, if you are using a “convenient” tool like Plesk, you are most-likely already $DEAD $BEEF, and don’t blame Perl for that.)
   • Somehow, this quote from the above-referenced Wikipedia article seems especially apropos:   “Generals always fight the last war, especially if they have won it.”
3. The coding practices of your entire system must be such that a Bobby Tables attack cannot by any means be mounted.   No “magic tool” on the planet can help you with this:   either your code is invulnerable to it by design, or you are $DEAD $BEEF and the entire world (except you, fool) already knows about it .
4. “Security” of a web-site is the kid-brother of “Total Reliability.”   It is completely astonishing to me how many production web-sites are out there which I can drop into 500 Internal Error just by innocently selecting a particular menu-option or pressing a particular button that the programmer did not bother to test.   (Quite literally, only one path through the application has ever been swept for mines.   No wonder the customers are unhappy.)   There are plenty of tools such as Selenium by which a thorough front-end functionality test can be built and automated, and even driven using Perl.   (There are, at this writing, 45 hits for “Selenium” at http://search.cpan.org.)   But it is very, very rarely done.
   • More than one time this year, I have been morally and pragmatically obliged to say to a (potential) client:   “Well, sir, before we can discuss enhancements to your web-site, first we must stabilize it, because right now I can drop it on its a*s more-or-less at will..”   This is not always popular ... or profitable ... but of course I won’t pick-up a client (or wish to, for I would surely lose much money...) whose understanding of their true business condition is less than realistic.