Category: DevSecOps

DevSecOps vs SecDevOps: Choosing the Right Security Model for Your Organisation in 2026

April 25, 2026

Security in software development is no longer optional — but the model you choose to implement it makes a profound difference to both security outcomes and delivery velocity. Two approaches dominate current practice: DevSecOps, which weaves security continuously throughout the development pipeline, and SecDevOps, which places security architecture as the absolute prerequisite before any code is written. Understanding when each is appropriate is one of the key judgment calls a security architect or leader must make in 2026.

What Is DevSecOps? The Shift-Left Imperative

DevSecOps is a cultural and technical transformation that embeds security practices into every phase of the Software Development Lifecycle (SDLC) — from initial design through deployment and post-release monitoring. Its governing principle is straightforward: the earlier a vulnerability is detected, the cheaper and less disruptive it is to remediate.

NIST’s Secure Software Development Framework (SSDF), published as SP 800-218, provides the authoritative reference for DevSecOps implementation. It organises practices around four groups: Prepare the Organisation (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Organisations that align their pipelines to SSDF are implementing DevSecOps in a structured, auditable way.

The five core principles of DevSecOps are:

  1. Shift-Left Security: Developers scan their own code as they build it, reducing the gap between writing vulnerable code and fixing it from weeks to minutes.
  2. Automated Security in the CI/CD Pipeline: Every commit triggers automated SAST, DAST, SCA, and secrets scanning — no manual review required at every step.
  3. Shared Security Ownership: Developers, DevOps engineers, and security specialists collaborate, with security functioning as an enabler rather than a gatekeeper.
  4. Security as Code (SaC): Policies are codified in machine-readable form, ensuring every deployment automatically inherits correct security configurations.
  5. Continuous Monitoring: Real-time monitoring of live applications detects emerging threats and feeds insights directly into the next sprint.

What Is SecDevOps? Security-by-Design at Scale

SecDevOps takes a more rigorous architectural stance: no development begins until the security architecture is fully defined and validated. While DevSecOps brings security earlier into development, SecDevOps positions it before development starts entirely — in the planning and threat modelling phase.

This methodology is standard in regulated, high-stakes environments: defence, financial market infrastructure, healthcare, and critical national infrastructure — sectors where a single exploitable vulnerability carries severe legal, financial, or operational consequences.

The five defining characteristics of SecDevOps are:

  1. Secure-by-Design Architecture: Applications are engineered around strict security standards from inception. Security is not retrofitted; it is foundational.
  2. Security as Code — Automating Compliance: Firewall rules, access controls, and compliance checks are codified and applied consistently across all environments.
  3. Infrastructure as Code (IaC) — Hardened Environments: Pre-hardened infrastructure is provisioned through code, eliminating insecure manual configurations.
  4. Automated Governance and Regulatory Compliance: The system continuously validates itself against HIPAA, GDPR, ISO 27001, or APRA CPS 234 and halts workflows on violation detection.
  5. Embedded Security Expertise: Security professionals are core team members from day one — not consultants parachuted in at review gates.

Head-to-Head: When Each Model Wins

Dimension DevSecOps SecDevOps
Delivery velocity High — security accelerates delivery Moderate — thorough design phase upfront
Regulatory environment Consumer, SaaS, general enterprise Finance, defence, healthcare, critical infra
Risk tolerance Moderate — iterative risk reduction Low — zero-defect policy preferred
Security ownership Shared across dev, ops, security Security-led, top-down governance
Cost model Lower — leverages existing pipelines Higher — dedicated security architecture team
Cloud-native fit Strong — microservices, auto-scaling Strong — IaC and hardened provisioning

Choosing the Right Approach: A Practitioner’s Framework

Choose DevSecOps if your organisation operates in a competitive consumer market, values rapid feature delivery, runs on cloud-native infrastructure, or cannot justify a standalone security department for every development team.

Choose SecDevOps if you operate under APRA CPS 234, ISO 27001, PCI-DSS, or HIPAA obligations; process highly sensitive data; manage financial market infrastructure; or cannot accept the reputational and regulatory consequences of releasing software with known vulnerabilities.

The most mature organisations adopt a hybrid posture: applying SecDevOps rigour during the design and threat-modelling phase, then leveraging DevSecOps automation during execution. In financial market infrastructure — where I work — this hybrid model is increasingly the norm: architectural security gates upfront, automated pipeline controls throughout, and continuous monitoring post-deployment.

The Australian Context: APRA and ASIC Expectations

For Australian organisations, APRA CPS 234 (Information Security) mandates that entities maintain information security capabilities commensurate with the size and extent of threats to their information assets. This obligation extends explicitly to software development and third-party dependencies. The ASIC Cyber Resilience Good Practices guide (2023) similarly emphasises secure-by-design as a baseline expectation for regulated entities, particularly those operating financial market infrastructure.

Organisations that cannot demonstrate secure development practices in their third-party assessments and vendor questionnaires are increasingly being flagged as elevated risk. Whether you choose DevSecOps, SecDevOps, or a hybrid, the expectation is the same: security must be systematic, evidenced, and auditable.

References and Further Reading

  • NIST SP 800-218 — Secure Software Development Framework (SSDF), Version 1.1 (2022)
  • OWASP DevSecOps Guideline — owasp.org
  • APRA CPS 234 — Information Security (2019)
  • ASIC — Cyber Resilience Good Practices (2023)
  • Gartner, How to Integrate Security Into DevOps (2024)
  • CISA, Shifting the Balance of Cybersecurity Risk: Principles for Security-by-Design (2023)

Threat Modelling with STRIDE: A Practitioner’s Guide to Systematic Security Design

April 16, 2026

Threat modelling is one of the most underutilised techniques in enterprise security. Despite being a core competency in frameworks ranging from NIST SP 800-154 to ISO/IEC 27001:2022 Annex A (A.8.25 — Secure Development Lifecycle), the discipline is frequently displaced by reactive vulnerability management and compliance-driven control assessments. STRIDE — Microsoft’s threat categorisation model — provides a structured, accessible framework for conducting threat modelling at the application and system design level, and for communicating findings to non-security stakeholders in terms they understand.

What Is STRIDE?

STRIDE is an acronym representing six categories of security threats, developed by Microsoft researchers Loren Kohnfelder and Praerit Garg in 1999 and widely adopted as a foundational threat modelling methodology. Each category maps to a specific security property being violated:

Threat Category Security Property Violated Example
Spoofing Authentication Impersonating a legitimate user or system component
Tampering Integrity Modifying data in transit or storage without authorisation
Repudiation Non-repudiation Denying having performed an action due to insufficient logging
Information Disclosure Confidentiality Exposing sensitive data to unauthorised parties
Denial of Service Availability Exhausting resources to prevent legitimate use
Elevation of Privilege Authorisation Gaining capabilities beyond those intended

The STRIDE Threat Modelling Process

STRIDE is applied through a four-step process that can be conducted at design time (most effective) or retrospectively against existing systems:

Step 1: Define the Scope and Create a System Model

Produce a Data Flow Diagram (DFD) that captures all components of the system: processes, data stores, external entities, and the data flows between them. The DFD is the primary artefact against which threats are enumerated. Each element type has a default set of applicable STRIDE threats: processes are susceptible to all six; data stores are primarily susceptible to tampering, information disclosure, and denial of service; external entities are primarily susceptible to spoofing.

Step 2: Enumerate Threats

Systematically apply each STRIDE category to each element in the DFD. The question for each combination is: “How could an attacker exercise this threat category against this component?” Tools such as Microsoft Threat Modeling Tool and OWASP Threat Dragon automate parts of this enumeration and maintain DFD-to-threat mappings.

Step 3: Assess and Prioritise Threats

Use DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) or CVSS-based scoring to prioritise identified threats by risk. This produces an actionable ranked threat list that can inform architectural decisions, security requirements, and remediation planning.

Step 4: Mitigate and Validate

For each prioritised threat, identify mitigating controls — whether preventive (authentication strengthening, encryption), detective (logging, monitoring), or architectural (trust boundary redesign, attack surface reduction). The threat model is then maintained as a living document and revisited when the system changes materially.

STRIDE in the Context of CISSP and Secure Architecture

STRIDE maps directly to CISSP CBK Domain 3 (Security Architecture and Engineering) and Domain 8 (Software Development Security). Understanding threat categories at a design level is a prerequisite for producing security architectures that address actual risk — as opposed to architecture that simply implements a control checklist.

In my work at Cboe, threat modelling forms part of the security review process for new application deployments. The DFD approach is particularly valuable because it creates a shared vocabulary between security architects and application development teams — reducing the friction that often arises when security reviews are perceived as compliance gates rather than design contributions.

STRIDE for Cloud and API-Heavy Architectures

STRIDE remains relevant in cloud-native environments, but its application requires adaptation. Key considerations for modern architectures include:

  • Spoofing in OAuth/OIDC flows: Token theft, confused deputy attacks, and client impersonation are spoofing threats specific to modern authentication patterns.
  • Tampering in CI/CD pipelines: Supply chain attacks that modify build artefacts or container images are tampering threats at the infrastructure level.
  • Information Disclosure in serverless: Environment variable leakage, excessive IAM permissions, and shared execution environment risks are information disclosure threats native to serverless architectures.
  • Elevation of Privilege in Kubernetes: Container escape, pod security misconfigurations, and RBAC weaknesses are privilege escalation threats that STRIDE helps enumerate systematically.

References and Further Reading

  • Shostack, A. — Threat Modeling: Designing for Security (Wiley, 2014)
  • Microsoft — STRIDE Threat Model Documentation
  • OWASP Threat Dragon — owasp.org
  • NIST SP 800-154 — Guide to Data-Centric System Threat Modeling
  • NIST SP 800-218 — Secure Software Development Framework (SSDF)
  • ISO/IEC 27001:2022 — Annex A.8.25: Secure Development Life Cycle
  • (ISC)² CISSP CBK — Domain 3: Security Architecture and Engineering