<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><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><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><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><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><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><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><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>>         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 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 class=""><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">gary.robinson@owasp.org</a><br>
</span><span class="">> <mailto:<a href="mailto:gary.robinson@owasp.org">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 class="">>         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 class="">>         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 class="">>         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 class="">>         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 class="">>         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 class="">>         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 class="">>         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 class="">>         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 class="">>         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 class="">>             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 class="">>             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 class="">>         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 class="">>     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">OWASP-Leaders@lists.owasp.org</a> <mailto:<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>
><br>
><br>
<span class="HOEnZb"><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 class="HOEnZb"><div class="h5">><br>
><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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>