Fix external reference relationship

Right now, each external reference can only be attached to one activity. It would make more sense to implement the model as follows:

# ===========================================================
# OWASP SAMM2 External Reference template/sample
# ===========================================================
#Link to the activity that this external reference belongs to
id:
  41069df2385749b190f46e8a776e6339

#Name of the external reference
name: 
  SafeCode 

#Link to the OWASP project
websiteURL: 
    "http://.../"

#Type Classification of the Document
type: ExternalReference

And then within the activity description, we would list IDs of applicable external references.

This needs to sync up with all the work Nessim and Phillippe are doing.

History from old repo: @yanfosec opened this issue on Nov 25, 2019 @yanfosec assigned @SebaDele and @23bartman on Nov 25, 2019 @nessimk commented on Nov 26, 2019

WARNING: This response grew in size from humble beginnings the more I thought about how we would do this. It's now rather long.

That would indeed be the way to go and adding that to the model and model parser is a simple task.

It does complicate the template though which we use to describe how elements of the model are formatted in the final markdown. Currently, the template is composed of simple values such as {{activity-a:longDescription}} (where activity-a is defined in a separate namespace file to point to the correct activity A yaml file. I described this in the branch nk-basic-pdf-from-object-model).

I had to extend this for the quality criteria to allow sub-item notation to reference only the text item from each element in an AnswerSet's values values list using {{answerset-a:values.text}}. External activity is probably different again in the sense that there'll be a variable number of them per activity. This means the template will need to support some form of iteration. For example: {{{for e in externalReferences-*: - e.name }}} which would be interpreted as. iterate over any namespaces in the namespace file whose name starts with externalReferences- and for each, expand any e.VAR to the corresponding value keeping any other formatting as-is.

That would lead to something like:

safeCode SEI This is of course doable, but it would involve:

preferably finding a templating solution that already includes logic. Mustache is a logic-less templating system on purpose, presumably to avoid ending up with the horrible mess that is JSP again. extending the current handling of {{ }} in templates to handle {{{ }}} as code constructs and deal with what's between the braces as cleanly (flex parser?) or messily (regex) as time allows. adding another layer of abstraction by having another script read the namespaces file, notice that there are entries formatted as foo-1, foo-2, etc., in this case externalReference-1, externalReference-2 and a meta template (what we currently call template) which contains {{externalReference.name}} and generate the final template with the statement duplicated for each matching entry in the namespace. My preference would probably go for the last option but that will open a can of worms about how to go from the one entry format in the (meta) template, here {{externalReference.name}} to multiple instances of it once it is expanded. Presumably you want a list of externalReferences in your final document, so the following (meta) template would give you the desired result):

{{externalReference.name}} but what happens when you want the final text to be something like (name1, name2, ...)? It can start getting messy pretty quickly.

For our current needs, we could stick with the last option and keep the implementation simple and specific to this use case. If we decide that we need more complex templating in the long[er] run, we should rethink the current approach guided by concrete requirements.

Unless anyone has a different view of course?

@23bartman commented on Nov 26, 2019 Hi all,

since we're not going to include references for SAMM 2.0, I would prefer to postpone this discussion to after the release. I am tagging the issue in that sense as well. @23bartman added the enhancement label on Nov 26, 2019

@yanfosec commented on Nov 26, 2019 I am OK leaving it off during the initial 2.0 release. The reason I was hoping to solve it is that my function has external references in it.

For now, I will move them to the actual description of activities and not under a specific label.

@23bartman assigned @nessimk on Dec 23, 2019

owaspsamm / core

Fix external reference relationship #79