ASVS v5.0 release checklist - rough workings

[tghosth]

We need to organize and also identify dependencies/order of performance.

Any other items you can think of @elarlang ?

Task list:

Finalise unordered draft:

• Change all levels.
  • Change levels to a number rather than tick boxes?
• Remove cwe mappings. Leave a blank space for cre? (CWE mapping will be dropped #1481, Link new requirements to CREs #2334 )
• must vs should (Must vs should #2554)

Reordering document:

• Reorder chapters
• Reorder sections
  • Section relevance questions? (Section and requirement relevance questions #1797)
• Reorder requirements based on level

Prepare RC1:

• Full renumbering
• Fix export scripts for new format
  • Include backwards compatible export formats? For example that makes levels back to tick boxes
• Announce rc1, we will only be accepting requirement wording changes but not new requirements, not level changes, not reordering?
• Chapter text (including Clarify intro to "V7 Error Handling and Logging" #1132)
• Update Glossary
• Grammar and terminology (lowercase vs uppercase grammar (original: 6.2.1 causes capitalization inconsistency) #1875, Fix backend/back-end terminology #2390)

Final release:

• Review and action RC1 feedback
• Create a release and release tag in GitHub
• Update read me
• Update translation instructions
• Write requirements scope explanations
• Update contributors information and working group

Post release:

• Prepare publicity on social and slack
• Update public website

[elarlang]

A lot of it is duplicate of #2456

Change levels to a number rather than tick boxes?

I think we have discussed and proposed it somewhere, numeric level should be more clear and easier to process.

edit: I opened a new separate issue for that: #2560

Remove cwe mappings. Leave a blank space for cre

Any mapping data should not be part of the releasable content. It can be in a separate mapping file to be "living" and by principle, it should be stored (only) in the OpenCRE side.

It is question of presentation layer, how to use and apply the mapping from OpenCRE.

Announce rc1, we will only be accepting requirement wording changes but not new requirements, not level changes, not reordering?

I don't find this limitation reasonable - this is basically the first moment we make noise and with the goal to get feedback. I would take all the feedback and make changes if we feel that we need to.

Maybe with a more clear steps for:

• A clear definition for level 1 - at the moment many throw opinions what should belong there without knowing, what it is
• Defined release strategy - a promise to users what is patch release and we don't do breaking changes into it