Closed hectoralicea closed 9 months ago
Hi @hectoralicea, that is possible. In case you open source (at least some of) your additions to the model, I will implement that for you. Deal?
Just to mention, I do understand that you want multiple extra fields. Your "implementationApproach" might allign with the existing field "evidence", see https://github.com/wurstbrot/DevSecOps-MaturityModel#usage.
Hi @hectoralicea, that is possible. In case you open source (at least some of) your additions to the model, I will implement that for you. Deal?
Deal. but, I'm also a developer and am open to making changes myself and submitting a pull request with the changes. Just need some pointers to where in the area of code should go to to review and make proposed changes.
Let me finalize the list.
The even more difficult part will be to be able to edit these new entries from the web app.
The even more difficult part will be to be able to edit these new entries from the web app.
Can you elaborate more your use case?
The even more difficult part will be to be able to edit these new entries from the web app.
Can you elaborate more your use case?
for example, I would like to manipulate the data as such 1.) mark if we have achieved that step, like we can now by clicking on the maturity bullet on this page: http://localhost:81/spiderweb.php 2.) When you click on it perhaps a popup entry box comes up in which you can describe how you met that maturity model. Describe your SOP (standard operating procedure) or technology (e.g. Jenkins, Ansible, etc), free form notes that can be used to capture that info 3.) perhaps add an owner of the process, or an example implementation.
What about this workflow which I am having in mind since a while: Every DSOMM-Activity is in a separate file containing an identifier. e.g.
Building and testing of artifacts in virtual environments:
risk: While building and testing artifacts, third party systems, application frameworks
and 3rd party libraries are used. These might be malicious as a result of vulnerable
libraries or because they are altered during the delivery phase.
measure: Each step during within the build and testing phase is performed in a separate virtual
environments, which is destroyed afterward.
id: CUHPfdrcUx40X6Kq4U0SGKodFm2VgcqHJt3nyCzTtCyv6AF9ud
meta:
implementationGuide: Depending on your envirnoment, usage of virtual machines or container technoligy is a good way. After the build, the filesystem should not be used again in other builds.
difficultyOfImplementation:
knowledge: 2
time: 2
resources: 2
usefulness: 2
implementation:
- Container technologies and orchestration like Docker, Kubernetes
- CI/CD Tools, e.g. Jenkins
samm2: i-secure-build|A|2
iso27001-2017:
- 14.2.6
As a DSOMM-user, I can place a yaml containing the customized information in a folder like data-customized, e.g.
id: CUHPfdrcUx40X6Kq4U0SGKodFm2VgcqHJt3nyCzTtCyv6AF9ud
risk: I do know better how to describe this risk
meta:
exampleImplementation: Please take a look at https://internal.local/xyz
The final merged result:
Building and testing of artifacts in virtual environments:
risk: I do know better how to describe this risk
measure: Each step during within the build and testing phase is performed in a separate virtual
environments, which is destroyed afterward.
id: CUHPfdrcUx40X6Kq4U0SGKodFm2VgcqHJt3nyCzTtCyv6AF9ud
meta:
implementationGuide: Depending on your envirnoment, usage of virtual machines or container technoligy is a good way. After the build, the filesystem should not be used again in other builds.
exampleImplementation: Please take a look at https://internal.local/xyz
difficultyOfImplementation:
knowledge: 2
time: 2
resources: 2
usefulness: 2
implementation:
- Container technologies and orchestration like Docker, Kubernetes
- CI/CD Tools, e.g. Jenkins
samm2: i-secure-build|A|2
iso27001-2017:
- 14.2.6
Modifications are tracked in git, so you get a history of changes.
Folder structure:
data
dimension
maturity level
fileX.yaml
fileY.yaml
data-customized
dimension
maturity level # overrides the level given in data
file1.yaml
file2.yaml
That would work really well. Just to clarify, for the changes tracked in git, we would have to fork the repo and the changes would be saved in our own git repo, right? Just validating.
Not sure if you need a fork, I think about layer container images, placing the data-customized into /var/www/html.
Hello I am looking at the same thing. I would like to add a new sub-dimension under implementation. I created a file under 'data\dimensions-subdimensions-activities\Implementation\Resiliency.yaml'
Implementation:
Resiliency:
Local Redundancy:
risk:
- Application is down in case of data center disaster.
measure: enable local redundancy.
difficultyOfImplementation:
knowledge: 1
time: 1
resources: 1
usefulness: 5
level: 2
Zone Redundancy:
risk:
- Application is down in case of regional disaster.
measure: enable zone redundancy.
difficultyOfImplementation:
knowledge: 1
time: 1
resources: 1
usefulness: 5
level: 3
Geo Redundancy:
risk:
- Application is down in case of multiple geo disaster.
measure: enable geo redundancy.
difficultyOfImplementation:
knowledge: 2
time: 2
resources: 1
usefulness: 5
level: 4
When I look at the result, I can see my new sub dimension in the matrix. However, the spiderweb is messed up (see picture below). Could you tell me the correct way to extend the model?
Is this model easily extendable? for example, in this yaml Implementation.yaml
I would like to add a few additional categories to the metadata, such as
implementationApproach
as shown below.