I've already walked through the process of mitigating SQL Injection vulnerabilities in code, but even in the most skilled hands with the best code reviewers, you're going to miss something. We're aiming for a system that is as difficult to crack as possible. You can never achieve total security (short of disconnecting the network card and melting all of the parts into a big giant blob, but then I'm sure there's someone who will argue that they can hack the data from it!)
The final rule missing from that post was to perform penetration testing. Doing so can be difficult. If you have a security team that is skilled in the art, it's probably best to leave the real pen testing to them. If you don't, or if you just want to preliminarily test before passing it off to your security team, there are several tools that automate pen testing.
Disclaimer: Most security tools can be used for good and evil. Running these tools on software you've written, installed on your own servers, or on servers that you are responsible for securing is "good" -- assuming you're allowed to even use these tools in your organization (obvious, right?). Running this on your online banking site to see if they're "up to spec" will hopefully get you a visit by the feds, especially if you decide to take advantage of the vulnerabilities it finds. In other words, don't do it. And if you do, you deserve the consequences of your actions.
For those who don't work in security, the question is often asked: "Why should these tools even be available? They're gold in the hands of a malicious user. " Tow which the inevitable conclusion is "They should be banned!" This thinking is referred to as Security through Obscurity. It simply doesn't work. You can't ban a tool because secrets are not kept well on the internet. Beyond that, these tools are often more useful to a pen tester than a black hat.
Bear in mind that these tools all have limitations since they're based on pre-programmed attack methods. A truly creative security engineer or black hat might find another method that your tool does not check for.
That said, I ran across this link on security-hacks.com entitled the Top 15 free SQL Injection Scanners. Some are designed for specific databases, some are general purpose. You'll find that more than one tool will prove useful and since they're free, you're out nothing if you give them each a shot. Of course, use them at your own risk. Never test live production servers unless you're operating within whatever maintenance window you have setup and have full (and tested) backups. You have no idea what these tools might actually do.
In addition, as with all penetration testing software, make sure you do a lot of additional research on the tool itself. You wouldn't buy a gun from a "guy on the street" (maybe you would? I wouldn't). If it's open-source, that's a good start. Check the community behind it and if you're skilled enough, review the source code yourself. Always consult Google. If it's commercial, avoid it unless you know the brand very well. Look for any hints of added malware. Unfortunately, you may find some security sites rank the tools as malware because they work as advertised so make sure you research well. If it's only fault is that it's designed to hack a web application, that's fine. Remember, we're trying to break into our applications so we can plug the holes and prevent someone else from discovering them. Nobody wants to get that frantic cell phone call at 3:00AM on a Saturday.