Integrating Security into Software Development – Secure Development Lifecycle (SDL)

The security landscape is complex, and including security into development can sound troublesome. However, there are structured ways to integrate security to every phase of software development. This approach is called Secure Development Lifecycle (SDL).

There are multiple different SDL frameworks, each have their pros and cons. Here are some well-known SDL models:

• Microsoft Security Development Lifecycle: This is considered the SDL of all SDLs. It was initially developed for Microsoft’s own development processes. It is almost universally applicable to all development projects. That of course means that it doesn’t go too deep into details.

• OWASP Software Assurance Maturity Model (SAMM): This framework is also technology agnostic and categorizes security based on business operations. SAMM also considers information security or an organizational level. It has its own auditing tool for implementation. SAMM has three different maturity levels.

• Building Security in Maturity Model (BSIMM): BSIMM is based on analysis of the security practices of over 130 companies. It considers which security practices are most often adopted, as well as which are the most difficult ones to adopt. BSIMM is not specific for technology companies, so it might not be specific enough for software projects on its own.

There are also standards (IEC 62443-4-1, ISO/IEC/IEEE 32675:2022) and other documents (NIST SP 800-218) to guide you when implementing an SDL.

Phases of SDL

Although the SDL models can vary quite a lot, the have a lot of common ground. In general, SDLs have the following phases:

1. Governance and Requirements

The governance and requirements section considers what kind of requirements does the operating environment set for the software, which kind of security competence different stakeholders need to obtain, and how are security risks managed.

2. Preparation and Environment

The preparation and environment section focuses strongly on threat modelling and environment hardening. Threat modelling is a tool for systematically identifying possible threats for the software system.

After threat modelling, a risk analysis is done. Risk analysis is in turn used in security requirements engineering.

3. Design

Security is often considered a design problem, so it’s no wonder that SDL also highlights secure design principles. The key concepts are defense in depth as well as minimizing the attack surface.

It is important to note that at this point, it is often realized that not everything expected in the requirements phase will be possible to include in the design.

4. Implementation

The implementation is about tools and practices that help ensure the developers can create a secure product. Examples include CI/CD pipelines, code reviews, and so on.

Again, in the implementation phase, the project might deviate from the original design.

5. Testing and Verification

This phase includes both software testing as well as implementation verification. Security testing focuses on the functionality and security of the product.

The idea is to ensure that security controls work as expected and that the software is resilient against cyber-attacks. Verification attempts to find the gaps between the original design and the implementation.

6. Monitoring and Response

Finally, the software lifecycle doesn’t end when the product is finished. In this phase, the operation of the deployed software is monitored.

Additionally, incident response and vulnerability management policies should be defined.

In Conclusion

The Secure Development Lifecycle (SDL) is a crucial approach that allows security to be integrated into every phase of software development. While the landscape of security can be complex, structured methods like SDL provide a roadmap for easier navigation.

Whether it’s the Microsoft Security Development Lifecycle, OWASP SAMM, or BSIMM, each SDL model offers its own advantages and should be tailored to specific project needs.