Request for feedback on ASVS v5 proposal: Repurpose section V1 and possibly eliminate it

[tghosth]

The ASVS Working Group is currently deciding how chapter V1 will look in ASVS v5.

The current proposal is as follows:

Requirement Type	Description	Examples	Proposed Location
Documentation / Inventory requirements	This is a new type of requirement which will define the documentation that an application needs to include about what is covered by certain controls or how certain controls are implemented. The idea is that it would not be possible to effectively implement certain requirements without good documentation of the details behind the control.	Not something that existed in 4.0 but we have similar things. E.g. v4.0.3-1.5.1, v4.0.3-1.8.1,	This would either be in V1 or alternatively be moved to the start of the relevant chapter.
SSDLC Process Requirements	Requirements mandating things like threat modelling, 3rd party vulnerability scans, design reviews, etc.	This was a big part of V1 in 4.0. e.g. v4.0.3-1.1.1, v4.0.3-1.1.2, v4.0.3-1.1.7,	Not in scope for ASVS
Security Process Requirements	Mandating security processes which will directly impact on the ability to implement requirements, such as an encryption key management process.	Exists in 4.0 in V1. e.g. v4.0.3-1.6.1	Should be converted into Documentation requirements.
Architectural Requirements	Requirements which form a basis on which other more detailed requirements rest	Lots exist in 4.0 in V1. e.g. v4.0.3-1.2.2 v4.0.3-1.6.2 v4.0.3-1.5.3 v4.0.3-1.6.3	Should move to the individual chapter where they are relevant.
Principles Requirements	States a security principle rather than a solid requirement.	v4.0.3-4.1.3	These should be reworded to either be an Architectural Requirement or a Documentation / Inventory requirement.

The rest of the requirements in ASVS should be implementation requirements which require specific controls to be implemented or functionality to be implemented in a certain way and should always be in the chapter to which they belong.

This means that V1 would be reserved for documentation requirements or possibly eliminated altogether if we moved documentation requirements to the chapters where they are more relevant.

The WG is keen to get feedback on this proposal.

[EnigmaRosa]

I am all too experienced with V1, so while I would be extremely sad to see it go, I think it is ultimately a necessary move. First of all, many of the architectural requirements are high level references to other chapters, and really only offer benefit if V1 is used as a standalone guide.
Do I like that SSDLC requirements will be eliminated? Not really. I could get into a philosophical debate about why these are important to application security, but I understand why it is being done.
Finally, to address the documentation aspect - would the intention be to add a new section to each chapter with document requirements? Or just guidance in each chapter that the relevant documentation would be helpful?

[tghosth]

I am all too experienced with V1, so while I would be extremely sad to see it go, I think it is ultimately a necessary move. First of all, many of the architectural requirements are high level references to other chapters, and really only offer benefit if V1 is used as a standalone guide.

Thanks, that is useful to hear :)

Do I like that SSDLC requirements will be eliminated? Not really. I could get into a philosophical debate about why these are important to application security, but I understand why it is being done.

Yeah we certainly aren't saying not to do them, just this isn't the place to describe them, especially as OWASP now has the Product Security Capability Framework project as well as OWASP SAMM.

Finally, to address the documentation aspect - would the intention be to add a new section to each chapter with document requirements? Or just guidance in each chapter that the relevant documentation would be helpful?

The current intention is that these would be actual requirements. Whether they would go in an initial chapter or in the chapter to which they relate would probably come to down to whether they relate to requirements across multiple chapters or not.

[tobyirvine]

I've worked a lot with the ASVS and agree with this proposal. Certainly, the "Principles Requirements" introduce a lot of subjectivity to an otherwise objective standard. As an example:

1.1.6 Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls.

This is achieved by assessing the app against the standard's other, more specific requirements. Anything additional and meaningful that 1.1.6 could reveal is probably a missing requirement from the ASVS.