Category:Summit 2011 OWASP Secure Coding Workshop Track

Revision as of 15:56, 19 January 2011 by John Steven (talk | contribs)

Jump to: navigation, search

T. secure coding.jpg

The track seeks to add to OWASP's cache of "secure code". Facilitators will chose a focus for each of the track's sub-sections addressing a "development scenario" developers consistently face in each application they build. Each sub-section aims to deliver secure functionality or code useful in helping developers build security into their application when addressing that development scenario even if it delivers only "code snippets". Two principals govern this track:

  • All track participants will support analysis, design, implementation, and testing activities for each section
  • Each track sub-section should deliver design and implementation useful as a leave-behind, for building security into applications

The first implementation of this track aims to deliver only code snippets because track organizers want freedom to select topics beyond what already exists in secure programming toolkits, if necessary. For those familiar with OWASP's ESAPI, the track will seek to:

  • Use existing ESAPI (or other OWASP project) material where appropriate
  • Roll-up and contribute back to OWASP projects, all applicable code developed during this track

Track sub-sections regarding "input validation" and AppSensor represent two OWASP project targets we've already included focus on.

Our goal will be to extend the practice of "building security into applications" without a preference for whether or not the application exists in a calcified form of maintenance or whether it's being developed in a green-field manner. Summarizing: the objective of each sub-section is to make our technology better not necessarily to raise awareness of its existence.


A set of facilitators, each with both a security and development background, will take turns leading their chosen focus. Facilitators will come prepared with their sub-section problem definition, session goals, and supporting material. Do not expect the facilitator to lead a lecture. Rather, expect the facilitator to come with a skeleton analysis of the development scenario and framework for analyzing the security challenge.

Expect facilitators to divide their sub-section into a list of goals for the development scenario. Facilitators will break the goal into intermediate objectives and will either delegate these objectives to participants or help to direct the conversation across contexts for participants. For example: during a sub-section on persistence frameworks, the facilitator may present risks associated with configuring and implementing auto-binding in a particular framework, then direct snippet implementation on other persistence frameworks, owned and implemented by participants themselves.


Participants will be expected to arrive with at least a conversational understanding (preferably experience) in the sub-topic area. They will be expected to contribute to analysis, design, implementation, and/or testing. Track participants will need to self-police each sub-section. If things get too introductory and forward progress stalls, participants can help a lagging participant "Get up to speed" with the rest of the session quickly in a side conversation/demo/hand-holding exercise.