8.3. Secure Development¶
8.3.1. Introduction¶
Security Development Lifecycle (SDL) is a management model proposed by Microsoft to guide the software development process from a security perspective. Used to help developers build more secure software, address security compliance requirements, and reduce development costs.
8.3.2. Steps¶
8.3.2.1. Phase 1: Training¶
All members of the development team must receive appropriate security training and have relevant security knowledge. The training objects include developers, testers, project managers, product managers, etc.
8.3.2.2. Phase 2: Determination of Security Requirements¶
Before the project is established, it is necessary to determine the security requirements in advance, determine the project schedule, and avoid security-induced requirements changes as much as possible.
8.3.2.3. Phase 3: Design¶
Determine the minimum acceptable level of security during the design phase. Consider what attack surface the project involves and whether it can be reduced.
Threat modelling of the project to identify where attacks are likely to come from, and consider which parts of the project require penetration testing.
8.3.2.4. Phase 4: Implementation¶
The implementation phase mainly involves tools, unsafe functions, static analysis and so on.
In terms of tools, it is mainly considered that the editors, linkers and other related tools used by the development team may involve some security-related issues. Therefore, it is necessary to communicate with the security team in advance on the version of the tools used.
In terms of functions, the main consideration is that many commonly used functions may have security risks. Insecure functions and APIs should be disabled, and functions recommended by the security team should be used.
Code static analysis can be assisted by related tools, and the results are combined with manual analysis.
8.3.2.5. Phase 5: Verification¶
The verification phase involves dynamic program analysis and attack surface re-audits. Dynamic analysis complements static analysis, and commonly used methods are fuzz testing and penetration testing. Fuzzing finds possible problems with a program by introducing a specific format or random data to the application.
Considering that the project often makes the final product inconsistent with the initial goal due to changes in requirements, it is necessary to analyze and consider the threat model and attack surface again in the later stage of the project, and correct it if there is a problem.
8.3.2.6. Phase 6: Release¶
After the program is released, it is necessary to respond to security events, and it is necessary to pre-set how to deal with security problems.
In addition, if the product contains third-party code, you also need to consider how to respond to problems introduced by third-party dependencies.