<commit_before>---
layout       : blocks/working-session
title        : Top 10 2017 - Process Discussion
type         : workshop
track        : Owasp Top 10 2017
technology   :
related-to   :
status       : done
when-day     : Mon
when-time    : AM-1
location     : Room-2
organizers   : <NAME>, <NAME>
participants : <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME> 
---

## Why


## What

How does the OWASP Top 10 get made, let's discuss and define. 
There's a reason why the OWASP Top 10 is what it is, but there needs to be transparency and a defined path for OWASP Top 10 project members and data call participants. 
Let's work on this so we can define the way forward for the 2017, 2020 and 2023 OWASP Top 10. 
 
## Outcomes 



## Who

The target audience for this Working Session is:

 - OWASP Top 10 2017 Track participants

## References

--- 

## Working materials

## Initial Brainstorm 
(from [J<NAME>](https://owaspsummit.org/Participants/remote/Josh-Grossman.html))

### What should the OWASP Top 10 look like?
- Stay as it is - top 10 list of application security *risks* based with some aggregation of categories?
- Change to a "league table" of specific CWEs purely based on data gathered?
- Evolve to consider wider issues in application security - this seems to have been the rationale behind "2017 RC1 A7 - Insufficient Attack Protection"?

### What should be the basis for the top 10?
- Stay as it is - Initial call for data and then the Top 10 produced based on the data plus the judgement of the project leaders/authors.
- Entirely data based - Top 10 based purely on the data gathered together with some normalisation or weightings?
- Data based with consensus - Top 10 initially based on normalised/weighted data but also modified based on community discussion/consensus.

### Does the preparation timescale make sense? 2017 process was:
- 20 May 2016      - Initial call for data
- 31 July 2016     - Official deadline for submitting data (after an extension from 20 July).
(based on the data released, the last large submission was 31 August 2016).
- 17 December 2016 - Release of the full dataset
- 10 April 2017    - Full RC1 document released.
- 30 June 2017     - Proposed end to comment period
- July 2017        - Proposed final released

Questions on the preparation time scale:
- Would it make sense to publish the proposed Top 10 list without writing the full document so as to gather feedback on the suggested Top 10 first?
- Does the ratio between time allocated to gathering data and time allocated to analysing the data make sense? (~3 months (~Jun-Aug) to gather compared to ~7 months (~Sep-Mar) to analyse).<commit_msg>Create Top-10-2017-Process-Discussion.md<commit_after>---
layout       : blocks/working-session
title        : Top 10 2017 - Process Discussion
type         : workshop
track        : Owasp Top 10 2017
technology   :
related-to   :
status       : done
when-day     : Mon
when-time    : AM-1
location     : Room-2
organizers   : <NAME>, <NAME>
participants : <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME> 
---

## Why


## What

How does the OWASP Top 10 get made, let's discuss and define. 
There's a reason why the OWASP Top 10 is what it is, but there needs to be transparency and a defined path for OWASP Top 10 project members and data call participants. 
Let's work on this so we can define the way forward for the 2017, 2020 and 2023 OWASP Top 10. 
 
## Outcomes 



## Who

The target audience for this Working Session is:

 - OWASP Top 10 2017 Track participants

## References

--- 

## Working materials

## Initial Brainstorm 
(from [<NAME>](https://owaspsummit.org/Participants/remote/Josh-Grossman.html))

### What should the OWASP Top 10 look like?
- Stay as it is - top 10 list of application security *risks* based with some aggregation of categories?
- Change to a "league table" of specific CWEs purely based on data gathered?
- Evolve to consider wider issues in application security - this seems to have been the rationale behind "2017 RC1 A7 - Insufficient Attack Protection"?

### What should be the basis for the top 10?
- Stay as it is - Initial call for data and then the Top 10 produced based on the data plus the judgement of the project leaders/authors.
- Entirely data based - Top 10 based purely on the data gathered together with some normalisation or weightings?
- Data based with consensus - Top 10 initially based on normalised/weighted data but also modified based on community discussion/consensus.

### Does the preparation timescale make sense? 2017 process was:
- 20 May 2016      - Initial call for data
- 31 July 2016     - Official deadline for submitting data (after an extension from 20 July).
(based on the data released, the last large submission was 31 August 2016).
- 17 December 2016 - Release of the full dataset
- 10 April 2017    - Full RC1 document released.
- 30 June 2017     - Proposed end to comment period
- July 2017        - Proposed final released

Questions on the preparation time scale:
- Would it make sense to publish the proposed Top 10 list without writing the full document so as to gather feedback on the suggested Top 10 first? [issue 6](https://github.com/OWASP/Top10/issues/7)
- Does the ratio between time allocated to gathering data and time allocated to analysing the data make sense? (~3 months (~Jun-Aug) to gather compared to ~7 months (~Sep-Mar) to analyse). [issue 7](https://github.com/OWASP/Top10/issues/6)
{'fraction_non_alphanumeric': 0.07533261416756562, 'fraction_numerical': 0.042430780294857966, 'mean_word_length': 3.446842525979217, 'pattern_counts': {'":': 0, '<': 35, '<?xml version=': 0, '>': 35, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1089052', 'n_tokens_mistral': 1742, 'n_tokens_neox': 1431, 'n_words': 794}