<div dir="ltr">>><span style="font-size:13px">3) Agree how to get from 1) to 2) - maybe some small trails? Can our community do it or do we need to wrap this into the RFP already under way?</span><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Based on the ongoing RFP for </span>assessments , formalising this information to be discussed in a board meeting is the next step. </div><div>That's why I set that on the wiki page because in the next board meeting you can add this document to the board's agenda for discussion and participation. </div><div>This is the first step, however, I think you need to work out a more detailed plan.</div><div><br></div><div>I like Glen's idea of his team proposing to manage. We need leaders to help manage because we do not have such resources.Someone needs to be accountable ;-)</div><div><br></div><div>Since the Security Framework is quite developed, I suggest to work out a proposal with this in mind for feasibility and maintainability.</div><div><br></div><div>You can indeed start with a couple of projects. It will be a big rebuild of the content, from wiki to Security Framework, divide and conquer.</div><div><ul><li>What kind of resources will be necessary ? (Technical editors, Markup editor etc) </li><li>You can create a budget and then submit a phased plan with clear timelines and goals<br></li><li>Example: Pilot Project </li><li><br></li></ul><b>OWASP Github project: centralise content from wiki to  Markdown format -</b></div><div><b>Pilot project:Transfer from Wiki to Github markdown :Code review & Developer guidelines</b></div><div><b><br></b></div><div><b>Phases:<br></b><ul><ul><li>Transfer Code Review_ raw content from wiki to mark down format  (x hours)</li><li>Transfer Developer Guide_raw content from wiki to mark down format (x hours)</li><li>Break down and verify redundant content (x hours /Who:?)</li><li>Technical review of content (x hours/price per hour resource)</li><li>Editorial review/Grammar (x hours/price per hour resource)</li><li>Setup Hosting Github (We have an OWASP github, check if that works out for this project)</li><ul><li>Access/Content Managers: Glen Ten Cate + bro</li><li>Backup Managers: Gary Robinson( make sure you have time ;-))</li></ul></ul><li>My advice is  to set a plan where you work out project by project ( starting with Code review, OpenSamm, Developer Guide and work from there) starting with a small pilot project.</li></ul>I can always help you work  out the plan, let me know if you need it.<br><div>These are just suggestions, but keeping in mind sustainability in such initiative is important for long term success.</div></div><div><br></div><div>Cheers</div><div><br></div><div>Johanna</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 5:36 PM, Gary Robinson <span dir="ltr"><<a href="mailto:gary.robinson@owasp.org" target="_blank">gary.robinson@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey All,<div><br></div><div>Johanna thanks for putting the proposal wiki page together (<a href="https://www.owasp.org/index.php/Category:OWASP_Github_Documentation" target="_blank">https://www.owasp.org/index.php/Category:OWASP_Github_Documentation</a>), I've added my name to the participant list and the Code Review Project to the project list.  I agree that since the responses so far are in favor of looking into this that we should make it into a more solid proposal.</div><div><br></div><div>How do we make this real?  I believe we need to do three things:</div><div>1) Work out where were are - engage with projects who are already experimenting with this, see what works, and how it could encompass all OWASP info.</div><div>2) Work out where we want to be - gain a consensus of how this documentation framework would look like, how we bring together the various duplicate descriptions into one 'golden source', how projects would use it, etc.</div><div>3) Agree how to get from 1) to 2) - maybe some small trails? Can our community do it or do we need to wrap this into the RFP already under way?</div><div><br></div><div>I agree with Johanna, if your interested in being part of this can you add your name/project to the wiki page and we can setup a mailing list, or plan a discussion at one of the summits.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Gary</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 10:44 AM, Glenn Ten Cate <span dir="ltr"><<a href="mailto:glenn.ten.cate@owasp.org" target="_blank">glenn.ten.cate@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Gary,<div><br></div><div>I really understand your pain in this topic and that's why we created the SKF project. A Central place for security knowledge.</div><span><div><br></div><div><span style="font-size:13px">>      1. Draft content that exists in the wiki.  This may be in varying</span><br style="font-size:13px"><span style="font-size:13px">>         states (correct, incorrect, lousy, confused, etc.) and is<br>>         visible to the internet and typically not clearly labelled as<br>>         draft.  Google ‘owasp purple monkey dishwasher’ for an example<br>>         of a draft wiki page visible to the internet.  This content also<br>>         needs to get cleaned up after a project release.</span><br></div><div><span style="font-size:13px"><br></span></div></span><div>This is the exact issue we tried to tackle, i'm not saying our markdown files are perfect but at least we try to have it on 1 place and be the authority of that information and keeping it up to date. We choose to take this upon us and yes it's a lot of work but we want to offer correct information.<br></div><span><div><br></div><div><span style="font-size:13px">>      2. Substandard descriptions/content can get into our docs.  Getting</span><br style="font-size:13px"><span style="font-size:13px">>         people to review every line/example/diagram/appendix is<br>>         difficult with a volunteer organization (as other threads have<br>>         discussed)</span><br></div><div><span style="font-size:13px"><br></span></div></span><div><span><font color="#222222">That is why we created a markdown format of all the knowledge base items and the code examples so they are easily reusable for everybody. Also because it's all in the Github everybody can create pull requests and they will be reviewed by the SKF team.</font><br></span></div><span><div><span><font color="#222222"><br></font></span></div><div><span><span style="color:rgb(34,34,34);font-size:13px">>      3. Duplications happen, as 10 different projects create/copy/paste</span><br style="color:rgb(34,34,34);font-size:13px"><span style="font-size:13px">>         their definitions of topics such as XSS, SQLi, CSRF, etc.  This<br>>         wastes effort in an organization already constrained of active<br>>         volunteers.</span><font color="#222222"><br></font></span></div><div><span><span style="font-size:13px"><br></span></span></div></span><div><span><span><font color="#222222">The problem with the current Wiki setup is that there is no real place of authority where people can find this information. We need to have one authoritative place where all the information / markdown files are located and synced to the specific projects or pages in the Wiki to display this information. The SKF could be this </font></span></span>authoritative place IMHO.</div><span><div><span><span style="font-size:13px"><br></span></span></div><div><span style="font-size:13px">>      4. Content gets out-of-date.  The work to create a new version of a</span></div></span><span>>         doc project takes years.<br><br><span style="font-size:small;color:rgb(34,34,34)">That's why we need 1 </span><font color="#222222">authoritative place where it's easy to reuse the information for everybody, also when we have such a place the content will be of higher quality and would evolve very fast because everybody is using it and give feedback if it's not correct or can be better.</font></span><div><span><font color="#222222"><br></font></span></div><div><span><font color="#222222">Actionable items:</font></span></div><div><span><font color="#222222">- We need to create an authoritative place where we will get all the information from and get consensus from the OWASP community.</font></span></div><div><span><font color="#222222">- We need to get consensus about the format being used for this central place, i would say use markdown format because it's easy to integrate into other projects or docs</font></span></div><div><span><font color="#222222">- We need to create some examples scripts in a Github repository how people can use the markdown files and sync or generate docs from the Central place of authority <br></font></span><div><div><span><font color="#222222"><br></font></span></div><div><span><font color="#222222">Just my thoughts, hope it can help and improve the OWASP brand and quality we want to achieve.</font></span></div><div><span><font color="#222222"><br></font></span></div><div><span><font color="#222222">Greetz,</font></span></div><div><span><font color="#222222">Glenn</font></span></div><div><span><font color="#222222"><br></font></span></div><div><span><font color="#222222"><br></font></span></div><div><span><font color="#222222"><br></font></span></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 11:09 AM, Steven van der Baan <span dir="ltr"><<a href="mailto:steven.van.der.baan@owasp.org" target="_blank">steven.van.der.baan@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm in favour of this as well. It would simplify to cross-reference<br>
between the documents.<br>
I would add projects like the Security Knowledge Framework into this as<br>
it already contains a lot of coding examples.<br>
<br>
Cheers,<br>
Steven.<br>
<span><br>
On 15/02/16 09:52, psiinon wrote:<br>
> I'm all for this, but there again in most cases I'd probably be<br>
> consuming this info rather than generating it ;)<br>
><br>
> We want to concentrate on making ZAP as good as we can, not<br>
> copy-and-pasting docs from other OWASP projects.<br>
> Theres loads of great content I'd like to include with ZAP if it was in<br>
> the right format.<br>
><br>
> We can (and do) link to other projects, but there are many times when<br>
> you want deeper integration.<br>
> A couple of ZAP examples:<br>
><br>
> When you raise an alert manually ZAP gives you a pulldown of common<br>
> vulns, and then fills out some boilerplate info if you select one of the<br>
> options.<br>
> Thats all taken from WASC as I couldnt fine a good OWASP alternative:<br>
> <a href="https://github.com/zaproxy/zaproxy/blob/develop/src/lang/vulnerabilities.xml" rel="noreferrer" target="_blank">https://github.com/zaproxy/zaproxy/blob/develop/src/lang/vulnerabilities.xml</a><br>
><br>
> I'd love to include a checklist in ZAP based on the testing guide - some<br>
> of the checks could be automatically completed when you perform some ZAP<br>
> actions, others would need to be manually completed by the tester, but<br>
> all could include more info (still in ZAP) explaining what the tester<br>
> needed to do.<br>
> This was a student project but it didnt go anywhere :(<br>
><br>
> Cheers,<br>
><br>
> Simon<br>
><br>
> On Sun, Feb 14, 2016 at 8:30 PM, Gary Robinson <<a href="mailto:gary.robinson@owasp.org" target="_blank">gary.robinson@owasp.org</a><br>
</span><span>> <mailto:<a href="mailto:gary.robinson@owasp.org" target="_blank">gary.robinson@owasp.org</a>>> wrote:<br>
><br>
>     Hi Folks,<br>
><br>
><br>
><br>
>     I want to reach out to the leaders and bring up the subject of OWASP<br>
>     docs projects, in fact all OWASP documentation including wiki and<br>
>     text available to our code projects as well.  I’ll try to keep this<br>
>     e-mail brief so won’t get bogged in details, but generally I want to<br>
>     know if the community experiences the same pains, see the same<br>
>     opportunities, or has other suggestions for improvement.<br>
><br>
><br>
><br>
>     The issues that can arise from our current method of developing our<br>
>     various docs include:<br>
><br>
><br>
</span>>      1. Draft content that exists in the wiki.  This may be in varying<br>
<span>>         states (correct, incorrect, lousy, confused, etc.) and is<br>
>         visible to the internet and typically not clearly labelled as<br>
>         draft.  Google ‘owasp purple monkey dishwasher’ for an example<br>
>         of a draft wiki page visible to the internet.  This content also<br>
>         needs to get cleaned up after a project release.<br>
</span>>      2. Substandard descriptions/content can get into our docs.  Getting<br>
<span>>         people to review every line/example/diagram/appendix is<br>
>         difficult with a volunteer organization (as other threads have<br>
>         discussed)<br>
</span>>      3. Duplications happen, as 10 different projects create/copy/paste<br>
<span>>         their definitions of topics such as XSS, SQLi, CSRF, etc.  This<br>
>         wastes effort in an organization already constrained of active<br>
>         volunteers.<br>
</span>>      4. Content gets out-of-date.  The work to create a new version of a<br>
<span>>         doc project takes years.<br>
><br>
>     I’m sure some readers will be mentally adding their own issues to<br>
>     this list.<br>
><br>
><br>
><br>
>     Proposal:<br>
><br>
><br>
>     Bringing together discussions with a few people over the last few<br>
>     years (you know who you are), I’m proposing the following: we write<br>
>     our docs with reusable resources.  What would this mean?  Something<br>
>     similar to the following:<br>
><br>
><br>
</span>>      1. We dump all of the content from our wiki, current docs,<br>
<span>>         descriptions in code tools, etc.  We put it into markup (as some<br>
>         projects are already doing) and add it to source code repositories.<br>
</span>>      2. We share doc markup files _across ALL docs and code projects_.<br>
<span>>         For example, imagine we have a folder for SQLi.  This directory<br>
>         contains the OWASP ‘golden source’ for SQLi definition,<br>
>         examples, code, tests, etc.  Repeat for all other AppSec issues<br>
>         (CSRF, cert pinning, etc.).  We use a mechanism to ‘compile’<br>
>         these markdown files into PDFs and integrate into code project<br>
>         HTML pages.<br>
</span>>      3. Similar to good coding projects, we control who can edit the<br>
<span>>         files under certain directories – people we know have expertise<br>
>         in an area.  Edits get peer reviewed before submission.  Other<br>
>         people can suggest edits and prove their experience to the<br>
>         existing team to join it.<br>
</span>>      4. We allow anyone to ‘include’ this markup file into their<br>
<span>>         project.  So if the Code Review Guide wants to add a section on<br>
>         SQLi, and needs a definition, I don’t write it (or copy from<br>
>         wiki), I simply include the relevant markup file.  Same for<br>
>         testing guide, dev guide, ZAP hints page, security shepherd info<br>
>         page, cheetsheet, and on and on.<br>
</span>>      5. We allow all of our docs, plus the wiki, plus all code projects,<br>
<span>>         to dynamically use an markup file update.  We make this ‘real<br>
>         time’.  This needs an example.  Say in March a massive change<br>
>         occurs in the world of SQLi.  Right now any project that talks<br>
>         about SQLi would need to manually go in and update, and those<br>
>         updates will be of varying quality and content.  If, instead,<br>
>         one (true) source file was update, all those other projects<br>
>         could spot the change and automatically rebuild themselves,<br>
>         meaning the next person to download a development guide PDF, or<br>
>         view the wiki, would get the updated SQLi information.<br>
</span>>          1. This is a big change.  This may be a controversial<br>
>             change.  _However it would greatly reduce our<br>
>             workload_ (only one markup document needs to get updated).<br>
>             It will also _greatly reduce review tasks_, as everyone is<br>
<span>>             sharing core content which is reviewed once.  It also<br>
>             improves our image to the world, as all projects have the<br>
>             same great descriptions and content.<br>
</span>>          2.   This change also improves our responsiveness.  Imagine a<br>
<span>>             heartbleed type issue being reflected in all OWASP code and<br>
>             documentation projects, as well as the wiki/cheetsheets,<br>
>             within a few days?  (simply the time for the team to agree<br>
>             updates to the text/examples/descriptions, review, and submit)<br>
</span>>      6.  We should also make these markup files available to anyone on<br>
<span>>         the internet (read only).  This way the source descriptions<br>
>         become an OWASP resource it itself, and anyone out there needing<br>
>         to spread the word on AppSec has easy access to rock solid,<br>
>         up-to-date definitions.<br>
><br>
>     This changes the model, from people like myself who run ‘projects’,<br>
>     to smaller expert teams who know ‘technologies’ (such as SQLi or IIS<br>
>     secure configuration).  It focuses people where they want to be on<br>
>     docs projects, but easily shares that knowledge across all OWASP<br>
>     (and more) projects.  It also means there’d never be another need to<br>
>     clean-up the wiki – it would always be based off the markup content.<br>
><br>
><br>
</span>>     *Big downside*: there’s a large piece of work to start it off.  All<br>
<span>>     content would need to get organized, put into sensible structure,<br>
>     converted to markdown, argued over, ‘experts’ defined and assigned,<br>
>     etc.  I doubt this would be a volunteer effort, and may need<br>
>     contractor involvement.  Could this be combined with the OWASP wiki<br>
>     redesign?<br>
><br>
><br>
>     So… the ask from the community, what are your thoughts? Could this<br>
>     be a viable option to save us time on docs/descriptions and increase<br>
>     quality?  Would there be funds to perform the initial conversion of<br>
>     everything into markup pages?  Would there be resistance to working<br>
>     in this new model?<br>
><br>
><br>
>     Gary<br>
><br>
><br>
>     _______________________________________________<br>
>     OWASP-Leaders mailing list<br>
</span>>     <a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a> <mailto:<a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a>><br>
>     <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
><br>
><br>
><br>
<span><font color="#888888">><br>
> --<br>
> OWASP ZAP <<a href="https://www.owasp.org/index.php/ZAP" rel="noreferrer" target="_blank">https://www.owasp.org/index.php/ZAP</a>> Project leader<br>
</font></span><div><div>><br>
><br>
> _______________________________________________<br>
> OWASP-Leaders mailing list<br>
> <a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a><br>
> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
><br>
_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
<br></blockquote></div><br></div>