Use a story tree to make the requirements more accessible to non-techies. about asvs

[elarlang]

Thank you for feedback, we had similar discussion some time (2 years) ago, #813 (comment)

My opinion is - techies need language for techies. Non-techies can not do the tasks which requires deep-techies knowledge. So I am failing to understand, what problem it solves from ASVS side?

To be clear: extra explanation in general is never bad, the question is - where it should be located (and who maintains and synchronizes it).

Where it may give extra value is to "translate" ASVS requirement to abstract business logical functional requirements, but this is out of ASVS scope.

In general - if some requirement text is not understandable, we need to fix the requirement. And there should be difference, is it not understandable because of bad text or because lack of knowledge on the topic. ASVS is not for education and requirement texts can not educate. Often they need to be abstract enough to be valid for different technologies.

Does it give you more ideas and questions? :)

[tghosth]

Hi @gobrtg,

Thanks for taking the time to suggest this.

A few thoughts:

• Specifically on 2.2.1 I think that the requirement needs some TLC as it is a little wordy and I have opened #1763 to deal with that separately. Overall for 5.0 we need to be clarifying requirements better.
• The ideal is that ASVS requirements should be understandable to developers and I think we need to get better at that for 5.0. On the other hand, we do try and keep the requirements themselves as short as possible.
• Currently, we have two mechanisms to provide extra context for ASVS requirements:
  1. The text surrounding the requirements although it isn't clear how often people are reading that.
  2. The CWE reference to explain which weakness it is aiming to address but again CWEs are not always super clear and sometimes the mapping is not exact.
• For 5.0, we are hoping to map to OpenCRE which is a far more varied and specific software security taxonomy. We also have a lot more input and control with OpenCRE.
• As a general point, I think the use of user stories to explain security controls would be really valuable and not necessarily limited to the ASVS but to explain controls/vulnerabilities in general. Mapping them to
• However, as was suggested in #813, this would probably be best pitched as a separate project. Having the user stories mapped using OpenCRE would be incredibly powerful as well (I don't think OpenCRE existed when the original issue was discussed).

In summary,

• I think your ideas would be super valuable combined with the resources here and here to further develop the OWASP User Security Stories project. If you want to help getting that OWASP project moving again and getting more involved with it, email me at firstname [dot] lastname [at] owasp [dot] org and I can try and help connect you to the relevant people :)
• If you are aware of other ASVS items that are not very understandable (as at the "bleeding edge version", please check if an issue has already been opened about them and if not, open an issue with your thoughts/suggestions.

Thanks again :)

[gobrtg]

Ok, I obviously read the plans for the asvs wrong. My bad. It was just meant as an idea, not criticism. Personally I love the work you have done, but I also have the problem of "selling it" to project and product management without me or team members having to be hands on. So that's what problem it was meant as a suggestion on how to solve. No matter, keep ut the good work! :)

[csfreak92]

This suggestion seems like another project/cheatsheet, maybe? Since this is out of ASVS scope.

[elarlang]

I also have the problem of "selling it" to project and product management without me or team members having to be hands on

Is it more security awareness issue for the leaders rather than ASVS is not "human" readable?

The point is - let's say ASVS is more human readable, would it solve the mentioned problem or the problem is somewhere else?

[gobrtg]

Just to be clear, I didn't mean that the ASVS should change its basic wording or language, only that the suggested construct could represent one possible way of making more people understand why there's a need for the different requirements. IMHO it could potentially help make the case for using ASVS for a lot more people, not only management. It's not a question of being human readable or not, it's a question of making what is read more comprehensible to more people.

In my experience devs usually both understand and want to implement the ASVS requirements. It's the people around them that don't necessarily see the need nor the value in giving time and resources to fulfill them. So maybe it's an awareness issue, but that was quite frankly what I got out of what I heard Grossman talked about regarding the plans for version 5, on the mentioned podcast.

[elarlang]

From my point of view it's awareness issue. Non-tech leaders just need to hire good tech persons for giving them good advice.

As it all related to @tghosth , then I leave it to him :)