← Foundations

Secure Development Lifecycle

How modern SDLC security frameworks map to OSA patterns -- from NIST SSDF to SLSA and CISA Secure by Design.

Security must be embedded throughout the software development lifecycle, not bolted on at the end. The industry has converged on a clear set of frameworks that define what secure development looks like, how to measure maturity, and how to assure supply chain integrity.

OSA provides two complementary patterns that cover the secure development lifecycle from architecture through implementation:

  • Secure SDLC (SP-012) -- end-to-end process covering threat modelling, secure coding, static and dynamic analysis, security gates, and vulnerability management across six lifecycle phases
  • Secure DevOps Pipeline (SP-028) -- CI/CD pipeline security, infrastructure hardening, secrets management, artifact signing, SBOM generation, deployment gates, and the developer-facing application security baseline (authentication patterns, input validation, structured logging, API security) with a practical Detect/Gap/Implement methodology

Framework Landscape

The authoritative frameworks for secure software development, all freely available and actively maintained:

NIST SSDF (SP 800-218)

The NIST Secure Software Development Framework defines high-level practices in four groups: Prepare the Organisation, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. SSDF is mandated by Executive Order 14028 for US federal software suppliers and forms the basis for CISA software attestation requirements. Version 1.2 (draft December 2025) adds continuous improvement and safe update delivery practices. SP 800-218A extends SSDF with AI-specific practices.

SSDF practices map directly to the NIST 800-53 controls used throughout OSA patterns. SP-012 implements the full SSDF practice set.

OWASP SAMM v2.0

The Software Assurance Maturity Model provides the measurement dimension that SSDF lacks. Five business functions (Governance, Design, Implementation, Verification, Operations) each contain three security practices with three maturity levels. SAMM answers the question SSDF cannot: how mature is our secure development programme?

SAMM complements OSA's self-assessment approach -- where OSA measures control implementation maturity per pattern, SAMM measures organisational software security maturity.

SLSA (Supply-chain Levels for Software Artifacts)

Maintained by the OpenSSF, SLSA defines incremental levels for software supply chain integrity. The Build Track (v1.0) progresses from basic provenance through hosted build services to hardened isolated builds with tamper resistance. The Source Track (v1.2) adds source code integrity requirements. SLSA provides the specific levels that SP-028's supply chain controls implement.

CISA Secure by Design

Published jointly with 17 international partners (including UK NCSC and Australian ASD), Secure by Design establishes three principles: own customer security outcomes, embrace radical transparency, and lead from the top. The voluntary pledge (200+ signatories) sets measurable goals including MFA adoption, default password elimination, and vulnerability class reduction. This is the regulatory direction of travel -- software manufacturers taking ownership of security outcomes.

NIST SP 800-204 Series

For cloud-native and microservices architectures, NIST published a five-part series covering service mesh security, attribute-based access control, and DevSecOps implementation. SP 800-204D (2024) specifically addresses software supply chain security in CI/CD pipelines -- the NIST-blessed companion to SP-028.

How OSA Patterns Map

The two OSA lifecycle patterns serve different audiences at different levels of abstraction:

  • SP-012 (Secure SDLC) serves security architects and AppSec teams. It defines the six-phase lifecycle process with NIST 800-53 controls at each gate. This is the governance layer -- what must happen and when.
  • SP-028 (Secure DevOps Pipeline) serves DevOps, platform engineers, and application developers. It defines the CI/CD pipeline from source code through deployment with security automation at each stage, and includes the developer-facing application security baseline covering authentication patterns, input validation, structured logging, and API security hardening. The Detect/Gap/Implement methodology helps teams assess and close gaps: detect what is already implemented, identify gaps against control requirements, and implement what is missing. This is the toolchain and implementation layer -- how to automate security and how to build it.

Together, these two patterns cover the full lifecycle from security requirements through automated verification to production deployment, with 75 NIST 800-53 controls mapped across them.

Historical Context

The original OSA lifecycle page (2008) evaluated ISO/IEC 15288, IEEE 1220, SSE-CMM (ISO 21827), ITIL, and COBIT as candidate reference models. None was formally adopted. Since then, the industry has converged around NIST SSDF as the authoritative practice framework, OWASP SAMM as the maturity model, and SLSA as the supply chain standard -- all freely available, vendor-neutral, and widely adopted. The original candidate models remain relevant for systems engineering (ISO 15288) and IT governance (COBIT 2019) but are no longer the right reference for secure software development.