Actually, your program has a huge security hole. It relies on Perl's @INC to find Digest::MD5. You have no way of knowing, from your program, what you are actually executing. Without changing your code, an attacker can execute any code by either changing the installed Digest::MD5, putting a different Digest::MD5 somewhere that Perl will find it first, changing perl's @INC, or even replacing perl.

Taint checking helps slightly by ignoring PERL5LIB, but it doesn't disable -I. Even then, a modified module in the usual @INC isn't caught, and no module in a modified @INC is caught.

Security isn't a yes-or-no property. It's just a "how much work do I have to do to defeat it" judgement. Locks and safes are rated not on how much security they provide, but how long they can withstand a determined attack.

If you don't know how to defeat your own program, you don't know enough about security. Your program might seem trivial, but if you are relying on it to verify file integrity, you've staked your security on it working correctly. You should know the various ways it can fail, and it appears that you don't.