DevSecOps is a culture, a practice of actively implementing security at every stage of the software development lifecycle. As a practice, it spells out frameworks that guide security engineers in their DevSecOps practices. As an organization, this model enables organizations to know their security position and level of DevSecOps adoption. DevSecOps is not limited to security testing. DevSecOps pulls through security verification, auditing, risks and compliance, security processes and an overview of why security is required, a clear understanding of what it means to be implementing DevSecOps and how effective your organization's DevSecOps program is.

The DevSecOps maturity model is a framework that can be used to mature the DevSecOps process within the organization. Following a maturity model also helps tell a story that includes the people, process, and technology changes that come with a DevOps-to-DevSecOps transformation, and brings together the very cultural, collaboration, and tool-chain improvements that development teams require to deliver secure and compliant software. Some of the DevSecOps activities are non-technical and more culture-oriented practices that fish out security issues.

4 levels of a DevSecOps maturity model using OWASP DSOMM Matrix https://dsomm.timo-pagel.de/

This matrix covers different dimensions and sub-dimensions

Dimensions consist of Build and Deployment, Culture and Organization, Implementation, Information Gathering to Test and Verification.

Sub-Dimensions include Build, Deployment, Patch Management, Design, Education and Guidance, Process, Application Hardening, Development and Secure Control, Infrastructure hardening, Logging, Monitoring, Application Tests, Consolidation, Dynamic Depth for Application, Dynamic Depth for Infrastructure, Static Depth for Application, Static Depth for Infrastructure, and Test Intensity.

DevSecOps Maturity Model

Level 1: Basic understanding of security practices

• Defined build and deployment process

• A patch policy is defined

• Automated PRs for patches

• Conduction of simple threat modelling on a technical level

• Information security targets are communicated

• Ad-Hoc Security training for software developers

• Security code review

• Security consulting on request

• Definition of simple BCDR practices for critical components

• Application Hardening Level 1

• Source Control Protection

• Versioning

• Isolated networks for virtual environments

• Simple access control for systems

• Usage of edge encryption in transit

• Usage of encryption at rest

• Usage of test and production environments

• Centralized system logging of security events and PII logging concept.

• Simple application, budget and system metrics

• Definition of quality gates

• Simple false positive treatment

• Treatment of defects with severity high or higher

• Test for exposed services

• Test of server-side components with known vulnerabilities

• Default settings for intensity

• High test intensity

• Stored secrets.

Level 2: Adoption of basic security practices

• Building, pinning and testing of artefacts in virtual environments

• SBOM of components

• Defined decommissioning process

• Environment depending on configuration parameters (secrets)

• Usage of trusted images

• Nightly build of images (base images)

• Reduction of the attack surface

• Usage of a maximum lifetime for images

• Each team has a security champion

• Regular security training for all and regular security training for security champions

• The reward of good communication

• Simple mob hacking

• App. Hardening Level 2

• Pre-Commit checks and validations

• 2FA

• Applications are running in virtualized environments

• Backup

• Checking the sources of used libraries

• Filter outgoing traffic

• The environment is hardened

• Usage of a security account

• Usage of internal encryption in transit

• Usage of security by default for components

• Virtual environments are limited

• Alerting, monitoring costs and visualising metrics

• Security unit tests for important components

• Simple visualization of defects

• Coverage of client-side dynamic components

• Usage of different roles

• Test network segmentation

• Test of the configuration of cloud environments

• Check for image lifetime

• Test cluster deployment resources, virtualized environments, cloud configuration

• Test the definition of virtualized environments

• Regular tests and deactivating of unneeded tests

Level 3: High adoption of security practices

• The signing of artefacts and code

• Handover of confidential parameters

• Inventory of dependencies and running artefacts

• Rolling update on deployment and same artefact for environments

• Usage of feature toggles

• Conduction of simple and advanced threat modelling on a business level

• Creation of threat modelling processes, standards and simple abuse stories

• Conduction of build-it, break-it, fix-it contests

• Conduction of collaborative security checks with developers and system administrators

• Security-Lessoned-Learned

• Approval by reviewing any new version

• Definition of a change management process and prevention of unauthorized installation

• App. Hardening Level 3

• Immutable Infrastructure and Infrastructure as Code

• Role-based authentication and authorization

• Centralized application logging

• Advanced availability, stability and web application metrics

• Deactivation of unused metrics and grouping of metrics

• Targeted alerting

• Security integration tests for important components

• Integration of vulnerability issues into the development process

• Treatment of defects with severity middle

• Usage of a vulnerability management system

• Coverage of hidden endpoint, input vectors and of sequential operations

• Usage of multiple scanners

• Weak password test

• Static analysis for important client-side components

• Test of client-side components with known vulnerabilities

• Analyze logs, check for malware and check for the new image version

• Creation and application of a testing concept

Level 4: Advanced deployment of security practices at scale

• Blue/Green Deployment

• Usage of a short maximum lifetime for images

• Creation of advanced abuse stories

• Aligning security in teams

• Conduction of collaborative team security checks

• Conduction of war games

• Regular security training for externals

• Full Coverage of App. Hardening Level 3

• Local development linting & style checks performed

• Limitation of system calls in virtual environments

• Microservice-Architecture

• Production near environments is used by developers

• Usage of a chaos monkey

• Correlation of security events

• Coverage and control metrics

• Defence metrics

• Metrics are combined with tests

• Screens with metric visualization

• High coverage of security-related module and integration tests

• Smoke Test

• Advanced visualization of defects

• Reproducible defect tickets

• Treatment of all defects

• Coverage analysis

• Coverage of service-to-service communication

• Load tests

• Test for unused Resources

• Exclusion of source code duplicates

• Static analysis for all components/libraries

• Static analysis for all self-written components

• Stylistic analysis

• Usage of multiple analyzers

• Check for known vulnerabilities

• Correlate known vulnerabilities in infrastructure with new image versions

• Test of infrastructure components for known vulnerabilities

A further explore of these security practices have risks and opportunities that are tied to their adoption. Designing a workflow that could cover some of these security practices from ground up based on the organization's business goals and security policies will strengthen security postures from all angles.