Difference between revisions of "Category:OWASP Github Documentation"

Latest revision as of 08:13, 16 February 2016

Proposal to transport OWASP wiki content Documentation to a centralize system

Problem Definition

The issues that can arise from our current method of developing our various docs include:

• Draft content that exists in the wiki. This may be in varying states (correct, incorrect, lousy, confused, etc.) and is visible to the internet and typically not clearly labelled as draft. Google ‘owasp purple monkey dishwasher’ for an example of a draft wiki page visible to the internet. This content also needs to get cleaned up after a project release.
• Substandard descriptions/content can get into our docs. Getting people to review every line/example/diagram/appendix is difficult with a volunteer organization (as other threads have discussed)
• Duplications happen, as 10 different projects create/copy/paste their definitions of topics such as XSS, SQLi, CSRF, etc. This wastes effort in an organization already constrained of active volunteers.
• Content gets out-of-date. The work to create a new version of a doc project takes years.

Proposal Details

• We dump all of the content from our wiki, current docs, descriptions in code tools, etc. We put it into markup (as some projects are already doing) and add it to source code repositories.
• We share doc markup files across ALL docs and code projects. For example, imagine we have a folder for SQLi. This directory contains the OWASP ‘golden source’ for SQLi definition, examples, code, tests, etc. * Repeat for all other AppSec issues (CSRF, cert pinning, etc.). We use a mechanism to ‘compile’ these markdown files into PDFs and integrate into code project HTML pages.
• Similar to good coding projects, we control who can edit the files under certain directories – people we know have expertise in an area. Edits get peer reviewed before submission. Other people can suggest edits and prove their experience to the existing team to join it.
• We allow anyone to ‘include’ this markup file into their project. So if the Code Review Guide wants to add a section on SQLi, and needs a definition, I don’t write it (or copy from wiki), I simply include the relevant markup file. Same for testing guide, dev guide, ZAP hints page, security shepherd info page, cheetsheet, and on and on.
• We allow all of our docs, plus the wiki, plus all code projects, to dynamically use an markup file update. We make this ‘real time’. This needs an example. Say in March a massive change occurs in the world of SQLi. Right now any project that talks about SQLi would need to manually go in and update, and those updates will be of varying quality and content. If, instead, one (true) source file was update, all those other projects could spot the change and automatically rebuild themselves, meaning the next person to download a development guide PDF, or view the wiki, would get the updated SQLi information.

This is a big change. This may be a controversial change. However it would greatly reduce our workload (only one markup document needs to get updated). It will also greatly reduce review tasks, as everyone is sharing core content which is reviewed once. It also improves our image to the world, as all projects have the same great descriptions and content.

 This change also improves our responsiveness.  Imagine a heartbleed type issue being reflected in all OWASP code and documentation projects, as well as the wiki/cheetsheets, within a few days?  (simply the time for the team to agree updates to the text/examples/descriptions, review, and submit)
We should also make these markup files available to anyone on the internet (read only).  This way the source descriptions become an OWASP resource it itself, and anyone out there needing to spread the word on AppSec has easy access to rock solid, up-to-date definitions.

This changes the model, from people like myself who run ‘projects’, to smaller expert teams who know ‘technologies’ (such as SQLi or IIS secure configuration). It focuses people where they want to be on docs projects, but easily shares that knowledge across all OWASP (and more) projects. It also means there’d never be another need to clean-up the wiki – it would always be based off the markup content.

Big downside: there’s a large piece of work to start it off. All content would need to get organized, put into sensible structure, converted to markdown, argued over, ‘experts’ defined and assigned, etc. I doubt this would be a volunteer effort, and may need contractor involvement. Could this be combined with the OWASP wiki redesign?

Draft Plan

OWASP Github project: centralise content from wiki to Markdown format

Pilot project:Transfer from Wiki to Github markdown : Code review & Developer guidelines

Phases:

• Transfer Code Review_ raw content from wiki to mark down format (x hours)
• Transfer Developer Guide_raw content from wiki to mark down format (x hours)
• Break down and verify redundant content (x hours /Who:?)
• Technical review of content (x hours/price per hour resource)
• Editorial review/Grammar (x hours/price per hour resource)
• Setup Hosting Github (We have an OWASP github, check if that works out for this project)

*Access/Content Managers: Glenn Ten Cate 
  *Backup Managers: Gary Robinson, Enrico Branca ( make sure you have time ;-))

Volunteers

Gary Robinson

Enrico Branca

Glenn ten Cate

Seba Deleersnyder

Participating Document Projects

Code Review Project

OWASP Security Knowledge Framework

OWASP Python Security Project

OWASP SAMM Project