Negligence is the first. Sometimes it's even willful. "Get this out in 3 weeks under budget, I don't care how." That leads to human error, which is more likely when you have underqualified people working on unrealistic deadlines.
I may, I have a bit of a vendetta for them.
> Negligence is the first.
Arguably, yes. Most of the comments when I posted mine indicated that negligence was the cause -- I was aiming to find the other ones. Still I somehow fail to understand how even pressure results in SQL injections -- nearly all languages I have worked with have a productivity reward/time saving for using parameterized SQL.
Code reviews should be about ensuring the integrity of the code base AND helping your developers write better code. If you fire someone on any teachable moment, your employees will never get any better. Mistakes should not equal firings for a first offence, that's a dead giveaway of a terrible manager. Making the same mistake twice is the inexcusable part.
There's an old story that's relevant here (I may get the specifics wrong): In the early days of Intel, before they were a behemoth, an engineer made a mistake that cost the company $50,000 (a huge sum at the time). The engineer was sure he was a goner, and many people were calling for this head. Gordon Moore (founder) was asked when he would be fired.
Moore replied "Why would I fire him? I just spent $50,000 training the man!"
The biggest reason is likely universities: I was there not too long ago (6-7 years), I wrote code that was secure against SQL injection - which lost me marks. They teach you to write insecure code and so help you God if you don't stick to what they have taught you.
Secondly is human error - that's to do with buffer overflows etc. You might say that we have static analysis, but...
Thirdly is that our static analysis tools simply are not "there" yet. They will catch the vast majority of vulnerabilities (especially when coupled together with contracts) but there are those corner cases that only a very creative security analyst will find.
Honestly though, if I was ever in a fire/hire position bringing SQL-injectable-code to a code review would be grounds for being fired on the spot.