0 / 24

Model 47 of 74 · Cybersecurity

DevSecOps Maturity Assessment

Assess how deeply security is embedded into your software delivery lifecycle — from design through build, test, deploy, and operate.

Pillars & areas

Prevent

Shift left

  1. 01Security Culture & Ownership
  2. 02Threat Modelling & Secure Design

Verify

Automate checks

  1. 03Secure Code & Build Pipeline
  2. 04Security Testing & Verification

Respond

Learn and adapt

  1. 05Deployment & Supply Chain Security
  2. 06Detection, Response & Feedback Loops

Levels

  1. 1Bolted-OnSecurity as afterthought
  2. 2Built-InIntegrated & automated
  3. 3ContinuousEmbedded & self-improving

01 Security Culture & Ownership

Do development teams own security outcomes, or is security someone else's problem?

0/4 answered

SC-1Who is responsible for the security of the software your teams build?

Think about whether developers consider security part of their job, or whether they expect a separate security team to catch everything.

SC-2How does your organisation build security knowledge within development teams?

Consider whether developers receive practical security training relevant to the code they write, or whether security awareness is limited to a generic annual course.

SC-3How are security requirements treated during feature planning?

Think about whether security is discussed when features are scoped, or only discovered as a concern during testing or after release.

SC-4How does your organisation incentivise security improvements versus feature delivery?

Consider whether security work competes with feature work for attention, or whether it has protected capacity.

02 Threat Modelling & Secure Design

Are security risks identified and addressed before code is written?

0/4 answered

TM-1When does your team first analyse the security implications of a new feature or service?

Think about whether threat analysis happens at the design stage, or only after the code is written and in review.

TM-2How does your team identify what an attacker could do to misuse a feature?

Consider whether the team thinks about abuse cases — not just what the feature should do, but what a malicious user could make it do.

TM-3How does your organisation maintain an up-to-date understanding of its application attack surface?

Think about whether anyone has a current view of all the APIs, services, data stores, and external integrations that could be targeted.

TM-4How does your team make secure design decisions for data handling and storage?

Consider whether the team has clear patterns for handling sensitive data — encryption, tokenisation, retention — or whether each developer makes their own choices.

03 Secure Code & Build Pipeline

Is security enforced automatically during coding and build stages?

0/4 answered

CB-1How does your pipeline detect security vulnerabilities in application code?

Think about whether security scanning happens automatically when code is committed, or only during periodic manual assessments.

CB-2How does your team prevent secrets from entering the codebase?

Consider whether API keys, passwords, or tokens have ever been committed to your repositories, and what controls exist to stop it happening.

CB-3How does your organisation secure the build pipeline itself from tampering?

Think about whether someone with access to the CI/CD system could alter a build to inject malicious code without detection.

CB-4How does your team ensure container images and build artefacts are secure before deployment?

Consider whether container images are scanned for known vulnerabilities, built from trusted base images, and kept up to date.

04 Security Testing & Verification

How thoroughly and continuously does the organisation test for vulnerabilities?

0/4 answered

TV-1How does your organisation test running applications for security weaknesses?

Think about whether applications are tested dynamically — with actual requests against a running instance — or only through static code analysis.

TV-2How does your team write and maintain security-focused tests?

Consider whether your test suites include tests that specifically verify security behaviour — not just functional correctness.

TV-3How does your organisation validate infrastructure and configuration security?

Think about whether infrastructure configurations — cloud settings, network rules, container orchestration — are checked for security misconfigurations before deployment.

TV-4How does your organisation use offensive security testing to validate defences?

Consider whether anyone regularly tries to break your applications and infrastructure from an attacker's perspective.

05 Deployment & Supply Chain Security

Are deployments and dependencies secured against tampering and known vulnerabilities?

0/4 answered

DS-1How does your organisation track and manage third-party dependencies?

Think about whether you have a current, accurate view of every open-source library and component running in production across all services.

DS-2How does your organisation verify that deployed artefacts have not been tampered with?

Consider whether there is an unbroken chain of trust from source code to what runs in production — could someone inject malicious code between build and deployment?

DS-3How does your organisation control what can run in production environments?

Think about whether anyone could deploy an arbitrary container or binary to production, or whether there are controls that restrict what is allowed to execute.

DS-4How quickly can your organisation patch a critical vulnerability across all affected services?

Consider the last time a critical CVE was announced in a widely-used library — how long did it take to identify exposure, apply fixes, and deploy across your estate?

06 Detection, Response & Feedback Loops

Can the organisation detect security issues in production and feed lessons back into development?

0/4 answered

DR-1How does your organisation detect security-relevant events in production applications?

Think about whether your applications generate security-specific telemetry — authentication failures, authorisation denials, input validation blocks — and whether anyone is watching.

DR-2How does your organisation respond when a vulnerability is discovered in production?

Consider the process from the moment a vulnerability is confirmed in a live system to the point it is fully remediated — how structured, fast, and repeatable is it?

DR-3How does your organisation turn security incidents and findings into preventive improvements?

Think about whether vulnerabilities found in production lead to changes that prevent the same class of issue from recurring, or whether the team just fixes the immediate bug and moves on.

DR-4How does your organisation measure and report on the effectiveness of its DevSecOps practices?

Consider whether leadership has data on security trends — are vulnerabilities being found earlier, fixed faster, and recurring less often?

Self-assessment report

DevSecOps

Answer the questions above and your report builds here: an overall score, a score and target for each area, and the three changes that matter most.

About this model

About the DevSecOps maturity model

Shipping software fast means nothing if you're shipping vulnerabilities with it. DevSecOps is the practice of embedding security into every stage of the software delivery lifecycle — from design through build, test, deploy, and operate — rather than bolting it on at the end.

This model assesses how well your organisation integrates security into development and operations workflows. It's not about having a separate security team that reviews everything at the gate — it's about making every developer, every pipeline, and every deployment inherently security-aware.

The best DevSecOps organisations don't slow down to be secure. They've made security so deeply embedded in how they work that it accelerates delivery by catching issues early, reducing rework, and building confidence in every release.

24 questions across 6 key areas, assessing how deeply security is woven into your software delivery lifecycle. Takes approximately 10-15 minutes to complete.

Scoring is based on 3 maturity levels per question. Your overall score reflects the average maturity across all areas, showing where security is genuinely integrated and where it's still an afterthought.

Who this assessment is for

  • Engineering and platform team leads
  • Security engineers and application security specialists
  • DevOps and site reliability engineers
  • CTOs, CISOs, and engineering managers
  • Anyone responsible for secure software delivery

The three maturity levels

  • Level 1 — Bolted-On: Security is separate from development. It happens late — through manual reviews, periodic penetration tests, or post-incident firefighting. Developers see security as someone else's job. Vulnerabilities are found in production because they weren't caught earlier. There's no security automation in the pipeline, and fixes compete with feature work for attention.
  • Level 2 — Built-In: Security is integrated into development workflows. Automated scanning runs in CI/CD pipelines, developers receive security feedback during code review, and threat modelling happens before major features ship. There are clear ownership and SLAs for fixing vulnerabilities. Security is still primarily driven by a dedicated team, but developers participate actively.
  • Level 3 — Continuous: Security is a shared responsibility embedded in engineering culture. Every team owns the security of what they build. Pipelines enforce security policies automatically, telemetry feeds back into design decisions, and the organisation continuously measures and improves its security posture. Security is not a phase — it's a property of the entire delivery system.

The 6 areas assessed

  1. Security Culture & Ownership — Do development teams own security outcomes, or is security someone else's problem?
  2. Threat Modelling & Secure Design — Are security risks identified and addressed before code is written?
  3. Secure Code & Build Pipeline — Is security enforced automatically during coding and build stages?
  4. Security Testing & Verification — How thoroughly and continuously does the organisation test for vulnerabilities?
  5. Deployment & Supply Chain Security — Are deployments and dependencies secured against tampering and known vulnerabilities?
  6. Detection, Response & Feedback Loops — Can the organisation detect security issues in production and feed lessons back into development?

How this model relates to other frameworks

  • OWASP SAMM (Software Assurance Maturity Model)
  • OWASP DSOMM (DevSecOps Maturity Model)
  • BSIMM (Building Security In Maturity Model)

Frequently asked questions

What is the DevSecOps maturity model?

Assess how deeply security is embedded into your software delivery lifecycle — from design through build, test, deploy, and operate. It is an original, simplified model with three maturity levels (Bolted-On, Built-In and Continuous), assessed through 24 questions across 6 areas: Security Culture & Ownership, Threat Modelling & Secure Design, Secure Code & Build Pipeline, Security Testing & Verification, Deployment & Supply Chain Security and Detection, Response & Feedback Loops.

How long does the DevSecOps assessment take?

Most people finish in 10–14 minutes. Each of the 24 questions has three concrete answer options. Your progress is saved in the page URL, so you can bookmark it and come back later.

How is the score calculated?

Each answer scores 1 (Bolted-On), 2 (Built-In) or 3 (Continuous). An area's score is the average of its answered questions, and the overall score is the average of the area scores, so every area counts equally. Scores run from 1.0 to 3.0.

Is my data stored or shared?

No. Your answers are never sent to a server. They are stored only in the page URL, which you control. Copy the link to share results with colleagues, or export a PDF or CSV report.

How should I use the results?

Start with "Where to focus" in your report. It lists the questions with the biggest gap to the target you set for each area, and shows what the next level looks like in practice. For a fuller picture, ask several people from different teams to complete the assessment and compare their links. Differences in perception are often as revealing as the scores themselves.