Secure development lifecycle

Rather than treating security as a review step before release, a secure development lifecycle assigns specific activities to specific phases: threat modelling at design, secure coding standards and static analysis during implementation, penetration testing and fuzzing during verification, and vulnerability monitoring after release. The CRA requires manufacturers to apply appropriate cybersecurity risk management measures throughout the product lifecycle, which in practice means having a documented secure development process, not just secure outcomes.

Core activities

• Threat modelling against the product's architecture and interfaces.
• Secure coding guidelines and static or dynamic analysis integrated into the build pipeline.
• Third-party and open-source component management, feeding into the SBOM.
• Security-focused testing distinct from functional testing.
• A defined process for handling vulnerabilities discovered after release.

Frameworks such as IEC 62443-4-1 for industrial products, or general models like a secure software development framework, describe this structure formally. The specific framework matters less than whether the activities are consistently applied and evidenced — auditors look for records that the process ran, not just a policy document describing it.

A secure development lifecycle overlaps substantially with the technical documentation expected under the CRA, since the process itself, and evidence that it was followed, forms part of the file.