Code review is in some companies a well established procedure but what about when you actually find an issue that goes beyond automated tools? Tooling cannot keep you distracted from the goal. You should put auditing as part of the SDLC with tooling or without it.
I cannot think about a software engineer (developer or not) not interested in scripting, seriously. Do you think you will always be in charge of just a couple of servers? Wait to see how your job evaporates and is shipped to an efficient team that handles farms of thousand of severs with a dozen individuals. So a word of advise: Do learn scripting.
I believe SQL injection account for the highest percentage of security holes exploitable nowadays in the wild. You better audit it.
Let's use as example Talend Open Source. All queries you use in your system are in a plain text file (wise approach) so just using few Unix Power Tools you can audit the code for sql injection:
find /path/to/talend/jobs/ -name "*.item"|xargs grep 'elementParameter.*name="QUERY'|grep '\+.*context\.'Simple snippets like the above can be included as part of your release/build script (Did I mention you should have those automated?). If there are hits then the build must stop. Period.