Secure Development Lifecycle (SSDLC) Guide: Secure by Design

Most organisations have secure coding standards and security tools, yet still ship vulnerable software, because nothing in the lifecycle decides which security work is required, who signs it off and what stops a release. A secure software development lifecycle (SSDLC) is that governance layer: security requirements written before code, design review, defined gates with acceptance criteria, and controlled release. This guide goes deeper than the Secure Coding Guide on lifecycle governance and secure by design software development, including CISA's programme, and maps the main frameworks (NIST SP 800-218, the Microsoft Security Development Lifecycle, the PCI Secure Software Lifecycle Standard, ISO/IEC 27001:2022 and OWASP SAMM) to concrete controls. Testing tools, triage and champions programmes are covered in the Application Security Guide. It is written for AppSec leads, engineering managers, product owners and release managers.

Key takeaways

• An SSDLC is governance, not tooling: it defines which security activities each change needs, the evidence each produces and who may accept residual risk.
• Requirements come first: security requirements and acceptance criteria written into the backlog are what make later gates objective; without them, every gate becomes a negotiation.
• Gates need criteria, owners and an exception path: SSDF PO.4.1 asks you to "Define criteria for software security checks and track throughout the SDLC"; a gate that cannot be passed by a documented, time-limited exception will be bypassed informally.
• Secure by design is an outcome, secure by default is a setting: CISA asks manufacturers to own customer security outcomes, and SSDF PW.9 turns that into a defined secure baseline shipped as the default configuration.
• Release is a security control: protected tags, signed artefacts, provenance and a second approver stop the attacks that bypass code review entirely, as the XZ Utils and Laravel-Lang incidents showed.

SDLC, SSDLC and the frameworks that define them

The system development lifecycle (SDLC) is the sequence a system passes through from initiation and requirements to design, build, test, release, operation and eventually disposal. A secure SDLC adds security activities, evidence and decision points to each phase without replacing the delivery method; agile teams deploying daily need the same controls at a faster cadence. NIST's abstract for SP 800-218 makes the point that few SDLC models "explicitly address software security in detail", so the SSDF is offered as "a core set of high-level secure software development practices that can be integrated into each SDLC implementation".

"Secure development lifecycle" and "SSDLC" usually mean your own lifecycle with security built in; the Microsoft Security Development Lifecycle (SDL) is Microsoft's programme, now ten practices. The frameworks overlap heavily, so pick one backbone and map the others to it.

Secure by design and secure by default

CISA's position is that security "is a core business requirement, not just a technical feature", applied in the design phase so fewer exploitable flaws reach the market, with responsibility taken at executive level. Its Secure by Design guidance, published with international partners, rests on three principles: take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top. Secure by default is the narrower, testable part: products are secure out of the box, with little or no configuration and at no extra cost, with examples such as multi-factor authentication, logging of potential intrusions and access control on sensitive data.

Secure by design defaults in practice

• Define the secure baseline: SSDF PW.9.1 asks teams to define a secure baseline by deciding how each security-relevant setting should be configured, and PW.9.2 to implement those as the defaults.
• Make insecure settings explicit: weakening a setting (disabling MFA, broad CORS) should be deliberate, logged and visible to the customer's administrators.
• Remove default passwords: generate unique credentials at install or force setup on first use.
• Ship logging on, without a premium tier.
• Treat the hardening guide as a defect list: each step a customer must take to be secure is a default you have not yet fixed.

The Secure by Design pledge and Secure by Demand

The pledge is voluntary and, in CISA's words, "not legally binding". Signatories commit to a good-faith effort over the following year and to publicly document measurable progress within one year of signing. Its seven goal areas translate directly into SDLC requirements:

Secure by Demand is the buyer's side: CISA's guide suggests asking suppliers whether SSO costs extra, whether MFA is on by default, which vulnerability classes they have eliminated, whether cloud logs are kept for at least six months at no extra charge, and whether a machine-readable SBOM is provided. Expect your own customers to ask the same. See the Third-Party Risk Management Guide.

The secure development policy

ISO/IEC 27001:2022 A.8.25 Secure development life cycle requires rules for the secure development of software and systems to be established and applied, and auditors look for a policy that is actually used. A useful secure development policy is short and decides things rather than restating good practice:

• Scope and tiers: which systems it covers (including internal tools, infrastructure as code and AI features) and a risk tier per application that sets how much assurance each needs.
• Required activities per tier: for example, tier 1 needs a threat model, ASVS Level 2 requirements, independent design review and a penetration test before major releases; tier 3 needs automated checks only.
• Roles and decision rights: who owns security requirements (product owner), who approves designs, who can accept residual risk and up to what severity, and who signs off releases.
• Gate criteria and the exception process, described below.
• Environment and supplier rules: separated environments (A.8.31), a protected build environment (SSDF PO.5.1) and requirements passed to suppliers (PO.1.3, A.8.30).
• Evidence: what records each activity produces and where, so attestation is a report, not a project.

Security requirements engineering

SSDF PO.1.2 asks organisations to "Identify and document all security requirements for organization-developed software to meet". Security requirements engineering is the discipline of turning risk, regulation and architecture into requirements that are specific enough to build and test. OWASP SAMM's Security Requirements practice describes the progression: at level 1, "High-level application security objectives are mapped to functional requirements"; at level 2, "Structured security requirements are available and utilized by developer teams"; at level 3, teams "Build a requirements framework for product teams to utilize". Its second stream, Supplier Security, extends the same requirements into supplier agreements.

• Sources: data classification, applicable regulation (payment, health, privacy), the threat model, the organisation's standards, and a verification standard. OWASP ASVS 5.0.0 is the usual catalogue for web applications, with Level 1, 2 or 3 chosen by risk tier.
• Abuse cases: for each significant user story, write the misuse case ("as a tenant user, I must not be able to read another tenant's invoices") alongside it.
• Make them testable: "the application must be secure" is not a requirement; "password reset tokens expire after 15 minutes and are single use" is.
• Security acceptance criteria: attach them to the story so the definition of done includes them, for example: given an unauthenticated request to the export API, the response is 401 and no data is returned; given a user without the finance role, the export button is absent and the API returns 403.
• Non-functional and platform requirements: logging, secret handling, dependency policy and default settings belong in a shared baseline inherited by every service, not re-written per project.

Design review

SSDF PW.1.1 asks teams to "Use forms of risk modeling", such as threat modelling or attack surface mapping, and PW.2.1 requires the design to be reviewed by a qualified person who was not involved in the design, or by automated processes, or both. In practice, trigger an independent review for new internet-facing services, new trust boundaries, authentication or authorisation changes, new sensitive data stores and AI features with tool access. Record decisions, accepted threats and added requirements; later gates check against them. The method itself is covered in the Threat Modelling Guide.

SDLC security gates and acceptance criteria

A security gate is a decision point where defined evidence must exist before work moves on. Gates fail by being so strict that teams route around them or so vague that they block nothing. Good gates are automated where possible, with published criteria, an owner and a fast exception path.

• Start gates in report-only mode: publish results for a few sprints, fix the noise, then enforce. Enforce on new findings first, with the existing backlog on a remediation plan.
• Exceptions are part of the gate: a documented risk acceptance with an owner, compensating controls and an expiry date, approved at a level set by severity. Track open exceptions as a metric.
• Keep the evidence: SSDF PO.4.2 asks for mechanisms to gather and safeguard the information that supports the criteria; gate results stored with the release record answer most audit and customer questions.

Secure release management

Several of the most damaging supply chain incidents never touched the reviewed source code. In the XZ Utils backdoor, the malicious code lived in release tarballs and a modified build macro rather than in the source most reviewers read. In the Laravel-Lang Composer compromise, a stolen access token was used to point existing release tags at malicious commits, so historical versions changed under their users. Release management controls address exactly this gap:

• Build releases from tagged source in a controlled pipeline, never from a developer machine, and compare published artefacts with what the pipeline produced.
• Protect release tags and branches so they cannot be moved or deleted without review, and require a second approver for release.
• Sign artefacts and publish integrity information: SSDF PS.2.1 asks producers to "Make software integrity verification information available to software acquirers". See the Code Signing Security Guide.
• Archive releases with provenance: PS.3.1 and PS.3.2 call for securely archiving each release and maintaining provenance data for its components. See the SLSA and Build Provenance Guide.
• Treat release identities as privileged: publishing tokens and signing keys should be short-lived or hardware-backed, scoped to one project and held by the pipeline rather than people. See the CI/CD Pipeline Identity Security Guide.
• Communicate security fixes: release notes that identify security fixes, CVEs with accurate CWE fields, and a tested rollback plan for every release.

Secure by design for AI features

AI features follow the same lifecycle with extra risks. The NCSC and CISA Guidelines for secure AI system development, published on 27 November 2023, organise their advice into four areas, secure design, secure development, secure deployment, and secure operation and maintenance, and follow a "secure by default" approach. NIST SP 800-218A, published in July 2024, is an SSDF community profile that adds practices and tasks for generative AI and dual-use foundation models and "should be used in conjunction with" SP 800-218. In an SSDLC this means adding AI-specific requirements (data provenance, model and prompt provenance, output handling, tool permissions), threat modelling agent behaviour at the design gate and adding prompt injection and abuse testing to the release gate. See the AI Agent Threat Modelling Guide.

Implementation roadmap

1. Baseline (months 1 to 2): inventory applications, assign risk tiers and owners, and assess against SAMM or SSDF to see where requirements, design and release practices are weakest.
2. Write the policy and gate criteria: one page per tier stating required activities, evidence, owners and the exception route. Agree it with engineering leadership, not just security.
3. Publish shared requirements: a baseline set every service inherits, plus ASVS-based requirement packs per tier, and add security acceptance criteria to the story templates.
4. Pilot with two or three teams for a quarter, gates in report-only mode; measure friction (time added, false blocks) and fix it before scaling.
5. Enforce progressively: merge and build gates first (automated), then design and release gates for tier 1. Keep a documented way to roll back any gate to report-only if it blocks delivery for reasons unrelated to risk.
6. Harden release: protected tags, signing, provenance and two-person release for tier 1 products.
7. Review annually: retire activities that find nothing and add ones incidents show are missing.

Decision guidance and measurement

• Which backbone: SSDF for US public sector sales or a supplier vocabulary; ISO 27001 controls if certified; PCI Secure SLC for payment software listing; SAMM to measure any of them; Microsoft's SDL practices as a completeness check.
• Small organisations: one policy page, a shared requirements baseline, automated merge and build gates, a lightweight design checklist and a release checklist. Skip formal design boards.
• Large organisations: tiering is essential, otherwise central review becomes the bottleneck; push tier 3 work to fully automated gates and spend expert time on tier 1.
• Hard versus soft gates: make a gate blocking only where the criterion is objective and the false positive rate is low; keep judgement-based checks as sign-offs with recorded rationale.

Metrics that show the lifecycle is working:

• Share of tier 1 and 2 changes with documented security requirements and a design review before build.
• Gate pass rate at first attempt, and mean time added to the release by security gates.
• Open security exceptions, their age and the share past expiry.
• Escape rate: vulnerabilities found after release compared with those caught at gates, by phase where they should have been caught.
• Releases built, signed and published entirely by the pipeline with provenance.
• Vulnerability classes eliminated (zero new findings for two or more quarters) through root cause work.

Framework mapping

Common failure patterns

• A policy nobody reads: a long document restating OWASP with no tiers, owners or criteria, so nothing applies to anyone.
• Gates without criteria: "security sign-off required" with no definition of pass, making every reviewer a bottleneck.
• Exceptions that never expire: risk acceptances granted to hit a date and never revisited, so the backlog of accepted criticals grows quietly.
• Security requirements added after build: findings raised at the release gate that should have been requirements, which is the most expensive time to fix them.
• Trusting the repository, not the release: reviewing source carefully but publishing from laptops or with long-lived personal tokens, the gap exploited in the XZ Utils and Laravel-Lang cases.
• Measuring activity, not outcomes: counting scans and training hours instead of escape rate and eliminated vulnerability classes.

Practitioner checklist

• Assign every application a risk tier and an owner, and publish the security activities each tier requires.
• Adopt one backbone framework (SSDF, ISO 27001 A.8.25 to A.8.29 or PCI Secure SLC) and map the others to it.
• Maintain a shared security requirements baseline and ASVS-based packs per tier; add security acceptance criteria to story templates.
• Require independent design review for new trust boundaries, authentication changes and AI features with tool access.
• Define each gate's evidence, blocking criteria and owner; run new gates in report-only mode first.
• Run a time-limited, owner-approved exception process and report open exceptions monthly.
• Define a secure default baseline (PW.9) and track every hardening step customers must take as a defect.
• Build, sign and publish releases only from the pipeline, with protected tags, provenance and a second approver.
• Publish a vulnerability disclosure policy and issue CVEs with accurate CWE fields.
• Reassess maturity yearly with SAMM and report escape rate alongside delivery metrics.

Standards and references

• NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
• NIST: SP 800-218 Rev. 1 (Initial Public Draft) SSDF Version 1.2
• CISA: Secure by Design
• CISA: Secure by Design Pledge
• Microsoft: Security Development Lifecycle Practices
• PCI Security Standards Council: Secure Software Lifecycle (Secure SLC) Standard
• OWASP: Software Assurance Maturity Model (SAMM) v2.0
• NCSC and CISA: Guidelines for Secure AI System Development

Related NHI Mgmt Group resources: Secure Coding Guide · Application Security Guide · Threat Modelling Guide · Software Supply Chain Security Guide · ISO 27001 Certification Guide