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.
I think you over-estimate the impact of universities. Many (perhaps most?) CS professors think of themselves as Applied Mathematicians. It's unrealistic to expect your linear algebra teacher to worry about style.
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 don't think that is an over estimation of the impact of universities. First, are the majority of university educated programmers really learning from CS professors? I'd venture that more programming is taught outside of the CS programs these days. Second, as someone finishing a degree in information security and having worked in IT for 14 years and IT security for 4 years, universities are not doing a great job in teaching applicable security. It is a rapidly evolving space and course materials just aren't keeping up.
I think you over-estimate the impact of universities.
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.
On point one - perhaps my expectations are lower. I think a CS degree signals a level of rigor that is absent in other degrees, but I don't pretend that the practicality is so high that people can be instantly useful. I assume that it takes 3 months of general training, and several more of "Here's how we do it here" before you can expect much. (As opposed to a Math major who would require programming training on top of it, or a History major who might be lost outright)
>>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.
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!"
Comments
If you want reasons other than negligence.
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.
I think you over-estimate the impact of universities. Many (perhaps most?) CS professors think of themselves as Applied Mathematicians. It's unrealistic to expect your linear algebra teacher to worry about style.
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 don't think that is an over estimation of the impact of universities. First, are the majority of university educated programmers really learning from CS professors? I'd venture that more programming is taught outside of the CS programs these days. Second, as someone finishing a degree in information security and having worked in IT for 14 years and IT security for 4 years, universities are not doing a great job in teaching applicable security. It is a rapidly evolving space and course materials just aren't keeping up.
I think we're saying the same thing. Universities aren't teaching security, so folks learn it elsewhere. Most people hiring new grads know this.
I may, I have a bit of a vendetta for them.
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.
On point one - perhaps my expectations are lower. I think a CS degree signals a level of rigor that is absent in other degrees, but I don't pretend that the practicality is so high that people can be instantly useful. I assume that it takes 3 months of general training, and several more of "Here's how we do it here" before you can expect much. (As opposed to a Math major who would require programming training on top of it, or a History major who might be lost outright)
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!"