How do we teach security?

During the conference, just about everybody made phrases like "when we tell the developers that they've got SQL Injection [or XSS, or LDAP injection, or ....]". I have a real problem with that. This is something I've complained about for awhile.

To understand where I'm coming from, think about how to fix those problems. Do we tell our developers "remove all SQL Injection"? I surely hope not. I would hope that we recommend that the developers perform output filtering (first) and business-rule input validation (don't remove "malicious" characters, just make sure it is what you think it is).

I really think that from a developers perspective, all vulnerabilities fall into one of three categories:

Semantic/data-use defects
These are the easy ones for automated scanners to find - html/script injection, SQL Injection, XML Injection, buffer overflows. Notice the category says "defects" not vulnerabilities. Meaning, you tell the developer "15 cases of unvalidated input. 16 cases of non-encoded output." The reason for this is that the fixes to these problems is something that developers should be doing anyway - not because it makes the app more secure (although, that's a nice side-effect), but so that the application functions properly. I remember many suns and moons ago a lone, < wouldn't work unless you actually encoded it properly - and if you're moving to XHTML, you're right back there.

Engineering defects
This is were [XC]SRF and privilege escalation fall. These happen not because of a forgotten function call or semantic drop that can be evaluated by a scanner, but an ethical hack or actual code review will discover. These are problems where the developer prolly did what they were told, they just weren't told the right thing to do.

Environmental defects
This is a catchall of anything else in the environment that causes the defect, including using the language improperly. Race conditions fall under this category. Directory traversal falls here. Backup files live here.

As I go through the types of vulnerabilities I find, all of them seem to fit nicely into one of these categories. Am I wrong? Is three just far too simplistic?

The good news for all you assessors out there - I would say that in many applications, a lot of the vulnerabilities are in the second and third categories - the things that tools can't find (well, moreso for the second category). Your job isn't going away anytime soon - unless you're just bad at it.