Secure Development Lifecycle. 

SDL generally provides a framework for applying approved security best practices across your regular SDLC. 

Two things are paramount to understanding SDL; 

1. Security can not be brushed aside! It has to be a part of the foundation. It is the concept of 'Security by Design.' 

2. The standard software development life cycle does not have straightforward steps for security activities. 

As such merging SDLC with an SDL framework guarantees that security is embedded in your product. 

                                                            Microsoft SDL Practices 

The Microsft SDL has about 12 SDL practices which everyone within the team must be familiar with in order to ensure the security of a product and also that of the end user. 

These practices are: 

1. Provide Training

2. Define Security Requirements

3. Define Metrics and Compliance Reporting

4. Perform Threat Modeling 5. 

5. Establish Design Requirements

6. Define and Use Cryptography Standards 

7. Manage the Security Risk of Using Third-Party Components 

8. Use Approved Tools 

9. Perform Static Analysis Security Testing (SAST) 

10. Perform Dynamic Analysis Security Testing (DAST) 

11. Perform Penetration Testing 

12. Establish a Standard Incident Response Process

1. Provide Training: Everyone has to be involved in the security aspect of a product, as such competent training should be done regularly to re-enforce security guidelines and requirements of software security. 

2. Define Security Requirements: There's the need to define the security requirements of the software, and this is usually done at the early stages of design and planning. It allows the development team to integrate security seamlessly and also reduce the chances of mishap. Some influential factors of security requirements are legal and industry requirements, internal standards and coding practices, past experiences, and known threats. 

3. Define Metrics and Compliance Reporting: There must be a minimum security standard that must be acceptable and engineering teams must strive to meet up with this basic standard. Aligning these security standards from the onset helps everyone in understanding the risks that come with security issues, it also helps in figuring out and fixing security issues during development, and applying this upgrade throughout the process. 

4. Perform Threat Modelling: This is a practice that allows the development team to consider, fashion out, structure, and discuss security indications of designs in the surrounding of their planned environment. It helps to mitigate expenses and security vulnerability while also increasing the efficiency of production. 

5. Establish Design Requirements: These are security requirements that are carefully contained in the contract that specifies the acceptable technical standards and also show the process through which the project should follow. Strict adherence to these guidelines is essential to avoid vulnerability and inconsistencies in production. 

6. Define and Use Cryptography Standards: Encryption is the key at this practice level. It is very important for all data, highly sensitive information, management, and control data to be encrypted and safe from every form of vulnerability including hacking, disclosure, and third-party attacks and also avoiding it getting into the wrong hands. Standard-level encryption models must be used, alongside industry-acceptable encryption libraries. 

7. Manage the Security Risk of Using Third-Party Components: Usage of third-party or open-source software projects must be carefully done to avoid any form of vulnerability or exposure. Understanding the impact of a security breach from a third party/outsourced software project on the larger product into which it is being embedded should be carefully done to reduce the chances of overexposure, loss, or negative security threats.

8. Use Approved Tools: Latest versions of approved security tools should be listed out and used at all times, and engineers must stay up to date with the latest security innovations.  

9. Perform Static Analysis Security Testing (SAST): This is a testing method that analyzes the source code to try to find security exposures and other threats that might make the product prone to outside attacks. 

10. Perform Dynamic Analysis Security Testing: This is a testing method where run-time verification of the software product is done to check the performance and functionality. This is only done when all the features are integrated and working. Several testing tools are used to attack and monitor the behavior of the software product, checks include memory corruption, end-user issues, and other severe security threats. 

11. Perform Penetration Testing: This is a testing method that encourages an organization to emulate a hacker and attack the software product to check for security threats and breaches. 

12. Establish a Standard Incident Response Process: Alongside the organization's devoted Product Security Incident Response Team(PSIRT), the Incident Response Plan is crucial in helping to address new security threats/exposures that may emanate with time. It has several four main categories which are: 

Preparation 

Detection and Analysis 

Containment, Eradication, and Recovery

Post-Event Activity.