SDL-POL-001 — Security Development Lifecycle Policy

1. Purpose and scope

This policy defines the Security Development Lifecycle (SDL) for all embedded products developed, maintained, or placed on the market by ACME Embedded GmbH (approx. 45 employees, business unit "Connected Sensors"). It applies to firmware, associated mobile/cloud companion components, and third-party components integrated into our products.

The SDL is a company-level foundation: every product certification and every CE declaration under the Cyber Resilience Act references this document. It is maintained within the quality management system (QM repository /quality/policies, Git-controlled, approval via merge request by the Managing Director).

2. Roles and responsibilities

Deputies are named in the QM role matrix (QM-ORG-003). No phase may be self-approved by the person who performed the work.

3. Lifecycle phases

The SDL follows six phases, loosely aligned with IEC 62443-4-1 practices (SM, SR, SD, SVV, DM, SG):

Phase 1 — Security requirements (SR). For each product/major release: identify intended use and reasonably foreseeable misuse, define the security context (network exposure, physical access assumptions), derive security requirements against CRA Annex I Part I. Output: Security Requirements Sheet (template SDL-TMP-010).

Phase 2 — Secure design (SD). Mandatory threat modeling (STRIDE-based, template SDL-TMP-011) for new products and for changes affecting interfaces, protocols, or trust boundaries. Design must document the attack surface (ports, services, debug interfaces, radio interfaces) and the secure-default configuration (see Section 5).

Phase 3 — Secure implementation (SM/SD). Coding rules: MISRA-C subset per SDL-STD-020; no hard-coded credentials; all third-party components recorded in the SBOM (CycloneDX, generated in CI). Mandatory peer review of every merge request; security-relevant changes require PSL review.

Phase 4 — Security verification and validation (SVV). Per release: SAST (pipeline stage sast), dependency/CVE scan of the SBOM, fuzzing of externally reachable parsers (protocol handlers, update parser), and execution of the secure-defaults checklist (SDL-CHK-030). Findings ≥ CVSS 7.0 block release.

Phase 5 — Release (SG). Security release gate chaired by the PSL. Entry criteria: completed checklists, resolved blocking findings, signed firmware image, updated technical documentation, support-period statement. Output: signed Release Gate Record filed in the release conformity dossier (see SDL-REC-002).

Phase 6 — Maintenance and end-of-life (DM). Vulnerability handling per PSM-PROC-002, including coordinated disclosure and ENISA/CSIRT notification timelines (24 h early warning / 72 h notification / 14 days–1 month follow-up as applicable). Security updates provided free of charge for the declared support period (minimum 5 years unless justified otherwise). EOL communicated ≥ 12 months in advance.

4. Risk-based tailoring

For minor releases (bugfix, no interface change) phases 1–2 may be satisfied by a documented delta assessment ("no change to threat model", signed by PSL). Full tailoring rules: SDL-STD-021.

5. Secure by design and secure by default

Every product must minimise its attack surface without configuration by the end user. Binding minimum defaults are defined in SDL-CHK-030 and verified at the release gate (no universal default passwords, debug/JTAG disabled in production, only required services enabled, secure update mechanism on by default).

6. Evidence and records

All records produced under this policy are quality records (retention: 10 years after last unit placed on market): security requirements sheets, threat models, review approvals, CI scan reports, release gate records, and the annual internal SDL conformity review (SDL-REC-002). Product technical documentation references this policy by ID and revision instead of duplicating it.

7. Review and improvement

This policy is reviewed annually in the management review and after any significant security incident. Changes are tracked in the revision history below.

Revision history