OWASP DSOMM

Level 1: Basic understanding of security practices: Versioning
Risk:
Deployment of untracked artifacts.
Measure:
Version artifacts in order to identify deployed features and issues. This includes application and infrastructure code, jenkins configuration, container and virtual machine images.
Difficulty of Implementation:
Knowledge: High (two disciplines)
Time: High
Resources: High

Level 2: Adoption of basic security practices: Require a PR before merging
Risk:
Intentional or accidental alterations in critical branches like main (or master).
Measure:
Define source code management system policies (e.g. branch protection rules, mandatory code reviews from at least one person, ...) to ensure that changes to critical branches are only possible under defined conditions. These policies can be implemented at repository level or organization level, depending on the source code management system.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Block force pushes
Risk:
Misuse of force push can lead to loss of work. It may overwrite remote
branches without warning, potentially erasing valuable contributions from team members. This can disrupt collaboration, cause data loss, and create confusion in the development process.
Bypassing the pull request process might remove an important code review step. This increases the risk of merging low-quality or buggy code into the main branch, potentially introducing bugs in the codebase.
Measure:
Mandate blocking of force pushes in the version control platform.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
High
Implementation:

Level 3: High adoption of security practices: Dismiss stale PR approvals
Risk:
Intentional or accidental alterations in critical branches like main (or master) through post-approval code additions.
Measure:
Implement a policy where any commits made after a pull request has been approved automatically revoke that approval, necessitating a fresh review and re-approval process.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
Very High
Implementation:

Level 3: High adoption of security practices: Require status checks to pass
Risk:
Organizations risk introducing broken builds, quality issues, and security vulnerabilities into their codebase.
Measure:
Mandate passing of security related specified status checks, like successful builds or static application security tests, before proceeding.
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Medium
Usefulness:
Very High
Implementation:

Level 4: Very high adoption of security practices: .gitignore
Risk:
Unintended leakage of secrets, debug, or workstation specific data
Measure:
.gitignore files help prevent accidental commits of secrets, debug, or workstation specific data
Difficulty of Implementation:
Knowledge: Medium (two disciplines)
Time: Low
Resources: Low

Level 5: Advanced deployment of security practices at scale: Local development linting & style checks performed
Risk:
Insecure or unmaintainable code base.
Measure:
Integrate static code analysis tools in IDEs.
Difficulty of Implementation:
Knowledge: Low (one discipline)
Time: Low
Resources: Low
Usefulness:
Medium
Implementation: