(Not that most academics write good code either, but this is not an academia/industry issue. It is a security expert/non-expert issue.)
Security experts write bad code. Non-security experts write bad code. Code, by default, should be assumed to be bad -- you're right far more often than you are wrong. That's why stringent review and re-review of code (both at the micro and macro level) are required to actually end up with a decently secure product.
I'm a huge fan of setting up adversarial teams for this. If you have two product teams in a company, have each team breaking the other's product; the closer you are to something, the less likely you are to see the bugs, so this model works phenomenally.
In my experience, security training (even up to the level of expert) helps people write better code only in terms of the most low-hanging fruit (SQLi, CSRF, basic XSS). But due to how close the author is to the code, it's nigh impossible for them to see the really bad bugs. But if you train your developers to break things and then point them at other teams' products, you're going to end up with a far more secure company.
Comments
Security experts write bad code. Non-security experts write bad code. Code, by default, should be assumed to be bad -- you're right far more often than you are wrong. That's why stringent review and re-review of code (both at the micro and macro level) are required to actually end up with a decently secure product.
I'm a huge fan of setting up adversarial teams for this. If you have two product teams in a company, have each team breaking the other's product; the closer you are to something, the less likely you are to see the bugs, so this model works phenomenally.
In my experience, security training (even up to the level of expert) helps people write better code only in terms of the most low-hanging fruit (SQLi, CSRF, basic XSS). But due to how close the author is to the code, it's nigh impossible for them to see the really bad bugs. But if you train your developers to break things and then point them at other teams' products, you're going to end up with a far more secure company.