Is SQL Injection a Terminable Offense?

I recently read an editorial on SQL Server Central by Steve Jones titled “Review Your Code” in which he asserts: “if you write code after today that’s susceptible to SQL Injection, you ought to be fired”.

I am certainly not going to disagree.  However, I don’t believe we should narrow the scope of the witch hunt to just the “coders”.  If you want to go on a termination rampage after a breach, you should probably look beyond just the code monkeys.

What about anyone who calls themselves an “architect”.  If you design a Swiss cheese system to begin with, what do you expect from the engineers?

What about the DBAs?  Why aren’t they standing up and demanding the use of parameterized queries to interact with their databases? Or better yet, demand applications interact with the database using only stored procedures so that the application user(s) only need(s) CONNECT and EXECUTE permissions?

What about QA? How does an application get deployed these days without at least some cursory security testing?

If the application is business critical, what about the decision makers?  Are they willing to write the checks to perform a REAL penetration test on the application?  (Not just a scan)

This list is by no means exhaustive. Depending upon your organization, there are probably plenty of other roles on the development team that should be security conscious too.  So when it comes time to hand out punishment after a breach, just firing the code monkey will probably not fix your problem.