Clarify the `implementation` scope

[ioggstream]

I expect

to clarify the implementation scope. For example:

• does it just reference tools and techniques (allowing reverse queries)?
• does it describe every and each product (mention junit, pyunit, .. ?)
• does it describe a category of products (eg. junit, pytest, pyunit, ...)?
• does it describe techniques (can't be reversed, see text)?

Idea: leave the descriptive part in a description field.

Example

Which model do we want for implementation?

Usage of a short maximum lifetime for images:
  ...
   implementation:
    - Sample concept:<br/>(1) each container has a set lifetime and is killed /
      replaced with a new container multiple times a day where you have some form
      of a graceful replacement to ensure no (short) service outage will occur to
      the end users.<br/>(2) twice a day a rebuild of images is done. The rebuilds
      are put into a automated testing pipeline. If the testing has no blocking
      issues the new images will be released for deployment during the next "restart"
      of a container. What has to be done, is to ensure the new containers are deployed
      in some canary deployment manner, this will ensure that if (and only if) something
      buggy has been introduced which breaks functionality the canary deployment
      will make sure the "older version" is being used and not the buggy newer one.

Automated PRs for patches:
    implementation:
    - *dependabot
    - *containers

[ioggstream]

Note, using gh url, we could retrieve sw topics with queries like this one

curl -i   -H "Accept: application/vnd.github.mercy-preview+json"  https://api.github.com/repos/github/super-linter/topics

then consider replacing implementation with a list of gh topics

[wurstbrot]

Copied from OWASP #dsomm Slack (by @ioggstream ):

hi! you can have a look at this repo https://github.com/ioggstream/dsomm-orm

• load dsomm data model on mysql
• load samm2 data model on mysq
• there are some simple sql queries
• there's a basic graphql api (very rudimental, the app is not core)

*************************** 49. row ***************************
  iid: CI/CD tools, eg. Jenkins
 refs: iso27001-2017:12.5.1,iso27001-2017:14.2.2,iso27001-2017:17.2.1,samm2:I-SD-1-A
value: 4
*************************** 50. row ***************************
  iid: Arachni
 refs: iso27001-2017:14.2.3,iso27001-2017:14.2.8,samm2:V-ST-1-A,samm:ST2
value: 4
*************************** 51. row ***************************
  iid: nmap
 refs: iso27001-2017:13.1.3,iso27001-2017:14.2.3,iso27001-2017:14.2.8,samm2:V-ST-1-A,samm:EH2-B
value: 5
*************************** 52. row ***************************
  iid: LogParser Jenkins Plugins
 refs: iso27001-2017:16.1.4,iso27001-2017:8.2.1,iso27001-2017:8.2.2,iso27001-2017:8.2.3,samm2:I-DM-1-B
value: 5
*************************** 53. row ***************************
  iid: https://github.com/mozilla/zest
 refs: iso27001-2017:16.1.4,iso27001-2017:8.2.1,iso27001-2017:8.2.2,iso27001-2017:8.2.3,samm2:I-DM-2-B
value: 5

[wurstbrot]

It would be nice to have to high lite OWASP Projects. This might enable more volunteers to provide information. E.g. from the https://owasp.org/www-project-integration-standards/ .

Option 1:

action1
  implementation:
    tools: 
    - *zap
    - *securecodebox
    - *arachni

The definition of the tools itself provides a flag owasp: true.

Option 2:

action1
  implementation:
  - *zap
  - *securecodebox
  - *arachni

The definition of the tools itself provides a flag owasp: true and tags: tool, defender and a url (see also https://github.com/wurstbrot/DevSecOps-MaturityModel/pull/71/files#diff-d4e7baf7602eead768f9dcae2cc751547594f6efa00423462edbd0514f8f6e3b).

I feel that the categories for the tools given in pr https://github.com/wurstbrot/DevSecOps-MaturityModel/pull/71/ is not flexible enough (therefore, I suggest something like tags). It is also an option to put owasp into the tags (might make sorting more easy).

OWASP itself has the following categories for projects: Builders, Breakers and Defenders, these could be included in the tags

[bkimminich]

You could add the type dimension of OWASP projects in tags as well (tool, code, documentation) along with the target audience (builder, breaker, defender) tags. This info should be available in the OWASP project websites in standardized form, and it might be preferable to creating a redundant data store for this.

[ioggstream]

@wurstbrot the #71 is older than the playground, and will be superseeded.

I think each tool could be structured like:

id: zaproxy
url: https://github.com/zaproxy/zaproxy
tags: [ "owasp:true", "tool", "owasp:defender", "github:dast", ... ]
description: |-
  blablabla long description for a cool tool

WDYT?

[wurstbrot]

@bkimminich I aggree that we shouldn't maintain information about existing owasp tags/types. I think DSOMM needs a structure in which we can fit the fetched information from existing pages/projects. @ioggstream showed the url as github URL, I do not think that we will get information about OWASP type/tags from there.

This info should be available in the OWASP project websites in standardized form, and it might be preferable to creating a redundant data store for this. Is the (planned?) standardized form documented somewhere?

[ioggstream]

@wurstbrot I get gh info using gh API. If owasp website has similar features we can do it too..