Okay, lets take a simple one: "Have you implemented input validation and output encoding?" What could go wrong, right? A naive developer with little security

Okay, lets take a simple one: "Have you implemented input validation and output encoding?" What could go wrong, right? A naive developer with little security understanding will look at that question and might even ask other members of the team about it. After a short bit of research the developer answers the question as "yes the application implements input validation and output encoding" based on finding that the framework utilized does in fact have input validation and output encoding functionality built in. Of course while the framework might have such controls and they may even be implemented for the particular code base, it turns out that relying on the framework alone isn't sufficient because there are many places in the code where that framework can be subverted or entirely bypassed. Rather than stopping at the framework controls the developer actually needed to perform a code audit and find everywhere user data might go to a sink which could result in unauthorized code execution, SQLi, or XSS. This is a particular scenario I've seen from the days of PHP magic quotes all the way to the latest ASP.NET request validation. It turns out the question was too simplistic. If we look at solving this problem we then need to dive into a great level of detail not only pertaining specifically to the framework controls available within the environment, but we must also look at how the code is implemented, ultimately scrapping the check-list only approach in favor of static code analysis. Of course if a management team only has a checklist and they are getting false answers as exampled above, they have no idea why they need static code analysis or should pay for the software and resources to use it.