Secure Software Development Lifecycle (SSDLC)

An SSDLC is not an additional project but a process discipline: security requirements, activities, and responsibilities are defined along all phases of software development – from requirements through design, implementation, testing, and release to operations. The underlying idea is to prevent or detect vulnerabilities as early as possible, because fixing them becomes more expensive with every later phase ("shift left"). One-off security tests shortly before release remain important, but they only examine the outcome; an SSDLC additionally addresses the root causes within the process. The approach is independent of the development model and can be integrated into traditional as well as agile or DevOps organizations.

The NIST Secure Software Development Framework (SP 800-218, version 1.1, final since February 2022) describes 19 practices with 42 tasks in four groups: "Prepare the Organization" (PO), "Protect the Software" (PS), "Produce Well-Secured Software" (PW), and "Respond to Vulnerabilities" (RV). Each practice includes implementation examples and references to other standards, yet is deliberately worded in a technology- and method-neutral way – which makes the SSDF well suited as a common language between development, security, and procurement. Since December 17, 2025, a draft of version 1.2 (SP 800-218r1, Initial Public Draft; the comment period ended on January 30, 2026) has also been available; it is not yet final and should therefore be treated as an outlook only.

For the development of generative AI and so-called dual-use foundation models, NIST published the supplement SP 800-218A in July 2024 ("Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile"). The Community Profile extends the SSDF practices with AI-specific tasks, recommendations, and references covering the entire lifecycle of model development – for example, the handling of training data and model artifacts. It is aimed at organizations that develop AI models, integrate them into systems, or procure them, and it is explicitly designed to be used together with SP 800-218.

While the SSDF describes what needs to be done, the OWASP Software Assurance Maturity Model (SAMM, version 2 since January 2020, currently version 2.2 from July 2024) answers how well an organization is already doing it. The model is structured into five business functions – Governance, Design, Implementation, Verification, and Operations – each with three security practices (15 in total), each of which is assessed across two streams and three maturity levels. SAMM is explicitly designed as a measurable model and captures not only coverage but also the quality of the activities; a prioritized improvement roadmap can be derived from the results. VamiSec provides a SAMM self-assessment at ssdlc-assessment.com.

Security gates are predefined criteria that an initiative must meet before it moves to the next phase – exactly what SSDF practice PO.4 ("Define and Use Criteria for Software Security Checks") calls for. Typical gates include: documented security requirements in the requirements phase (PO.1), a threat model in design (PW.1), secure coding standards and automated checks such as SAST and software composition analysis during implementation (PW.5, PO.3), code reviews and security testing before release (PW.7, PW.8), and protected build and release artifacts with verifiable integrity (PS.1, PS.2). In operations, continuous vulnerability identification, prioritization, and root cause analysis (RV.1–RV.3) close the loop. Effective gate criteria are formulated in measurable terms – for example, the share of gates passed, the time to remediate identified vulnerabilities, or the recurrence of the same vulnerability classes; SAMM anchors this governance in the "Strategy & Metrics" practice.

The Cyber Resilience Act (Regulation (EU) 2024/2847, in force since December 2024) makes a working SSDLC mandatory for manufacturers of products with digital elements: Annex I Part I defines requirements for product properties (including security by design and secure default settings based on a risk assessment), while Part II defines requirements for vulnerability handling – including the creation of a software bill of materials (SBOM). Actively exploited vulnerabilities and severe incidents become subject to mandatory reporting from September 11, 2026 (early warning within 24 hours, further details within 72 hours, final report after 14 days or one month, respectively); the regulation applies in full from December 11, 2027. Security updates must be provided over a support period of, as a rule, five years – without documented development and vulnerability handling processes, this is hard to demonstrate in a defensible way.