Separation of model and data

[ivareri]

This touches on https://github.com/wurstbrot/DevSecOps-MaturityModel/issues/60, https://github.com/wurstbrot/DevSecOps-MaturityModel/issues/56, https://github.com/wurstbrot/DevSecOps-MaturityModel/issues/43, https://github.com/wurstbrot/DevSecOps-MaturityModel/issues/211.

As a newcomer to the project it is somewhat hard to understand how to use it effectively and properly. One one hand, there's a nifty heat-map where you can select if a control/action is implemented. On the other hand you need to edit files in the docker container to provide evidence/comments/etc. And once you get into the YAML file, there is no clear guidance on what is the DSOMM model itself, and what is user supplied data for a given assessment.

If I understand the YAML files correctly, Evidence, Assessment, Implemented and Comments are user supplied (for each assessment), while all other fields should be considered part of the DSOMM model?

My suggestion\wish would be to split data from the model. Perhaps keep the YAML files for the model, but use some other storage for the user supplied data (csv file, sql database, favorite cloud table storage, etc).

I must admit i don't quite see the end-goal of the team-based assessment in https://github.com/wurstbrot/DevSecOps-MaturityModel/issues/237. Wouldn't this be better solved with each team having their own data, and possibly have a way of aggregated reporting on an organization level? (heat-map based on % of teams/apps having activity X implemented)

Having UUID's (https://github.com/wurstbrot/DevSecOps-MaturityModel/issues/242) for activities makes it easier to separate "model" and "data", as you have a consistent and unique field for referencing back to the model.

[wurstbrot]

Hi @ivareri , thank you for your input.

If I understand the YAML files correctly, Evidence, Assessment, Implemented and Comments are user supplied (for each assessment), while all other fields should be considered part of the DSOMM model?

Correct, but now teamImplementend and teamEvidience.

My suggestion\wish would be to split data from the model. Perhaps keep the YAML files for the model, but use some other storage for the user supplied data (csv file, sql database, favorite cloud table storage, etc).

What do you mean with data? User supplied data or and which activities are implemented? Or do you mean application and YAMLs in general (that is done).

I must admit i don't quite see the end-goal of the team-based assessment in #237.

When I perform organization-based assessments for multiple teams, I would like to see the average quickly.

Kind regards Timo

[ivareri]

Hi @ivareri , thank you for your input.

Thanks for the reply. I had to do a bit of a mental rewind here, hope the answers makes sense.

If I understand the YAML files correctly, Evidence, Assessment, Implemented and Comments are user supplied (for each assessment), while all other fields should be considered part of the DSOMM model?

Correct, but now teamImplementend and teamEvidience.

My suggestion\wish would be to split data from the model. Perhaps keep the YAML files for the model, but use some other storage for the user supplied data (csv file, sql database, favorite cloud table storage, etc).

What do you mean with data? User supplied data or and which activities are implemented? Or do you mean application and YAMLs in general (that is done).

I was only considering the YAMLs, not the application.

With data I was thinking of anything user supplied. So 'Evidence', 'Assessment', 'Implemented' and 'Comments'. With model I was thinking of anything else in the YAMLs.

So, the model remains (mostly) static. No changes to this during assessments.

All data generated during an assessment I would like to store in a table storage of some sort.

For example	assessment_id	uuid	Evidence	Assessment	Implemented	Comments
1	a340f46b-6360-4cb8-847b-a0d3483d09d3	yaddi	yaddi	true	Comment!
2	a340f46b-6360-4cb8-847b-a0d3483d09d3	Other evidence		false

I could then use assessment ID to differentiate between assessments, whether it be by team, application or date.

I must admit i don't quite see the end-goal of the team-based assessment in #237.

When I perform organization-based assessments for multiple teams, I would like to see the average quickly.

Hum, I don't see the implemented solution scaling very well. Sure, if you're consulting and assessing a sample of teams or applications this might work. But say you have 10-15 teams, and some teams have more than one application? With the data, or results if you will, stored in a database it would both scale and be easy to find average, worst team, best team, focus area, etc.

[wurstbrot]

Hi @ivareri,

I like to separate data and activity definitions (e.g. YAML). Maybe we find a volunteer next year.

A database might be possible to integrate with the new metricCA project. There, a database is needed and it might be good to use the same database for DSOMM.

[piyushs131]

Before i will dive into addressing the issue at hand, I wanted to discuss the best approach for generating UUID Would it be feasible to tackle this by integrating a new MySQL database?

By using MySQL built-in functionality we can automate UUID generation for new entries, enhancing efficiency and reliability. Alternatively, we could proceed with implementing UUID generation logic directly within the DSOMM codebase.

Given the importance of this issue its crucial to clarify the approach before start working on this issue.

Thanks