Define security requirements “ Identify and document security requirements early in the development life cycle and make sure that subsequent development artefact s are evaluated for compliance with those requirements. When security requirements are not defined, the security of the resulting system cannot be effectively evaluated ” This is perhaps a subset of the “ Architect and design for security policies” practise, although it does serve to emphasize that s ecurity requirements, like safety and functional requirements, need to be specified at the outset and need to be shown to have been implemented. Figure 4 shows how the automation of requirements traceability can help . M odel threats “ Use threat modelling to anticipate the threats to which the software will be subjected. Threat modelling involves identifying key assets, decomposing the application, identifying and categorizing the threats to each asset or component, rating the threats based on a risk ranking, and then developing threat mitigation strategies that are implemented in designs, code, and test cases ” Identifying high risk areas such as data endpoints and communication between domains provides key focal points throughout the development process. Addressing those focal points throughout the development lifecycle is key to optimizing the security of the system as a whole.