Secure Development Lifecycle (SDLC)

A Secure Development Lifecycle (SDLC) — sometimes called Secure SDLC or SSDLC — is a product development process that embeds security activities at each phase of development rather than treating security as a final-stage add-on. The concept was popularised by Microsoft's Security Development Lifecycle (SDL), published in the early 2000s, and has since been formalised in standards such as ISO/IEC 27034 (Application Security) and NIST SP 800-64. An SDLC typically includes: security requirements definition, threat modelling, secure design review, secure coding guidelines, static analysis (SAST), dynamic testing (DAST), penetration testing, and security-focused code review. The principle is 'shift left' — finding and fixing security issues early in development when they are cheapest to address.

The CRA's Annex I essential requirements include obligations that directly map to SDLC activities:

• Risk assessment: Manufacturers must assess cybersecurity risks — this is the threat modelling phase of the SDLC.
• Secure design: Products must be designed with security in mind (secure by design and secure by default).
• Testing: Products must be tested for security — specifically to verify the absence of known exploitable vulnerabilities.
• Vulnerability management integration: The SDLC must connect to post-market vulnerability handling — vulnerabilities discovered post-launch must be able to be fixed through the development process.

The Annex VII technical documentation requirements implicitly require SDLC records: risk assessment documents, design review records, security test reports, and code review findings must all be retained as evidence of conformity.

A CRA-aligned SDLC should include the following activities by phase:

Requirements phase: Define security requirements based on the product's threat model; identify applicable CRA essential requirements; document regulatory compliance requirements.

Design phase: Conduct architecture threat modelling (STRIDE or PASTA methodology); design security controls for identified threats; review design against CRA Annex I requirements; document security architecture decisions.

Implementation phase: Apply secure coding standards; use SAST tools in the CI/CD pipeline; conduct peer security code review for security-sensitive components; manage dependency selection and SBOM tracking.

Testing phase: Conduct DAST/fuzzing against network-exposed interfaces; perform penetration testing of the final product build; verify all threat model mitigations are implemented and functional.

Release phase: Final security review; SBOM generation and sign-off; declaration of conformity preparation; CVD policy publication verification.

Maintenance phase: SBOM-based vulnerability monitoring; CVD report intake and triage; security patch development; security advisory publication.

CRA-covered products often combine hardware and software — embedded systems, IoT devices, industrial equipment. SDLC for hardware-software products requires extending traditional software-focused SDLC practices:

• Hardware threat modelling: Physical attack vectors (JTAG access, UART debug, chip-off, side-channel analysis) must be in scope for the threat model.
• Hardware security review: PCB layout review for debug interface exposure; component selection review for security features (HSM availability, TrustZone support).
• Manufacturing security: Security-critical manufacturing steps (key injection, Secure Boot fuse programming, JTAG lockdown) must be documented and verified processes.
• Supply chain review: Hardware component supply chain security review — sourcing from trusted suppliers, component authenticity verification.

These hardware-specific SDLC activities should be documented in the Annex VII technical file alongside software-focused security activities.