This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Talk:Summit 2011 Working Sessions/Session072

Jump to: navigation, search

Historically OWASP (and the Web Application Security space in general) has failed (with some notable exceptions) to create productive relationships with developer teams that achieved measurable and 'shipped' results (note for example the lack of 'Frameworks developers' in the OWASP ecosystem). This session will look at the current problems and propose a number of solutions to bridge the gap with the people who ultimately have the final impact on an application's security, the developers.

John's comment on Jeremiah's "Open Letter to OWASP" blog post : "...I think the foremost reason why OWASP hasn't been able to reach out to the developer community is a fairly ignorant attitude to software development.

In IT security I constantly meet experts who say "I used to code" and claim that they know software craftmanship because of that. If you poke them you quickly understand that "used to code" means non-enterprise, command-line Pascal hacks done in Emacs back in the nineties.

Then these security experts try to communicate with real developers who manage hundred thousand lines of Java, C#, Python, PHP, or JavaScript. Developers who know their IDEs, who read blogs and books on refactoring, unit testing, design patterns, and clean code. Developers who on a daily basis produce business enabling features and functions. Needless to say the security expert fails in convincing these developers that he or she knows what's really important.

To start with, security is at the bottom of the software food chain. Before security you deal with features & functions, uptime, usability, performance, and maintainability. Then security. So when we meet with developers we need to be humble. They create more business and value for their organizations than we do.

Secondly, security experts need not only meet with developers and business people. We need to learn what they do, how they do it, and why they do it. Mocking developers because you found a bug with your fuzzer won't build trust and produce more secure software in the long run.