OWASP DSOMM

Level 2: Adoption of basic security practices: Number of vulnerabilities/severity
Description:
Communication can be performed in a simple way, e.g. text based during the build process. This activity depends on at least one security testing implementation.
Risk:
Failing to convey the number of vulnerabilities by severity might undermine the effectiveness of product teams. This might lead to ignorance of findings.
Measure:
Measurement and communication of vulnerabilities per severity for components like applications. At least quarterly.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High

Level 2: Adoption of basic security practices: Number of vulnerabilities/severity/layer
Description:
Communication can be performed in a simple way, e.g. text based during the build process. This activity depends on at least one security testing implementation. Layers to consider (SCA):

Layers to consider SAST/DAST:

Risk:
Failing to convey the number of vulnerabilities by severity and layer (app/infra) might undermine the effectiveness of product teams. This might lead to ignorance of findings.
Measure:
Measurement and communication of vulnerabilities per severity for components like applications and split it depending on the layer (e.g. app/infra). At least quarterly.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High

Level 2: Adoption of basic security practices: Patching mean time to resolution via PR
Risk:
Without measuring Mean Time to Resolution (MTTR) related to patching, it is challenging to identify delays in the patching process. Unaddressed vulnerabilities can be exploited by attackers, leading to potential security breaches and data loss.
Measure:
Measurement and communication of patching Mean Time to Resolution (MTTR) in alignment with Service Level Agreements (SLAs), conducted at least on a quarterly basis. This includes the measurement of the existence of a properly configured automated pull request (PR) tool (e.g., Dependabot or Renovate) in a repository. In addition, the measurement of the time from opening an automated PR to merging it.
Average time to patch is visualized per component/project/team.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Medium
Usefulness:
High

Level 3: High adoption of security practices: Fix rate per repo/product
Description:
Validating Findings by Security Engineers Pros:

Validating Findings by Security Engineers Cons:

Pushing Findings Directly to Product Teams Pros:

Risk:
Not integrating vulnerability handling into the development process may result in product teams ignoring findings.
Security joke: We will gain 100% false negatives.
Measure:
Integration of findings into the development process. E.g. adding findings to the backlog of products teams
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Generation of response statistics
Risk:
No or delayed reaction to findings leads to potential exploitation of findings.
Measure:
Creation and response statistics (e.g. Mean Time to Resolution) of findings. This is also referred to as Mean Time to Resolve.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Low
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: SLA per criticality
Description:
Validating Findings by Security Engineers Pros:

Validating Findings by Security Engineers Cons:

Pushing Findings Directly to Product Teams Pros:

Risk:
Not integrating vulnerability handling into the development process may result in product teams ignoring findings.
Security joke: We will gain 100% false negatives.
Measure:
Integration of findings into the development process. E.g. adding findings to the backlog of products teams
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Medium
Resources: Medium
Usefulness:
High
Implementation:

Level 4: Very high adoption of security practices: Patching mean time to resolution via production
Risk:
Without measuring Mean Time to Resolution (MTTR) related to patching, it is challenging to identify delays in the patching process. Unaddressed vulnerabilities can be exploited by attackers, leading to potential security breaches and data loss.
Measure:
Measurement and communication of the time from the availability of a patch to its deployment in production in alignment with Service Level Agreements (SLAs), conducted at least on a quarterly basis. Average time to patch is visualized per component/project/team.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Medium