Secure Development Lifecycle: Importance & Learning

What Is a Secure Development Lifecycle?

The secure development lifecycle (SDL) is a set of best practices to support software security and
compliance requirements. It covers every aspect of software development to implement security.

Why is the Secure Development Lifecycle Important?

Why do we need SDL in the world of Cloud Native, DevOps and DevSecOps, where everything moves fast and there is no time to follow a heavyweight process like SDL? Just implement, integrate and automate SAST, DAST, SCA and Pen testing and we should be good on the security side. Right?

It’s not that simple.

It is important to build security from the ground up in today’s complex and changing landscape of threats. SDL provides a framework and best practices to implement security and privacy controls and consideration throughout all phases of the development.

Modern development processes and methodologies have changed the way we build software. However, we must still follow each development step, formally thinking through the requirements, architecture and design, through testing the software, writing test cases and scripts, and so on. These processes are critical. However, implementing them without a foundational process or framework cannot ensure secure software. Instead, it overwhelms the development team who are probably already struggling to meet the release timelines with security bugs to be fixed. So why skip the foundation step ofbuilding secure software?

Microsoft Secure Development Lifecycle

Of the many SDL models, Microsoft Security Development Lifecycle (MS SDL) is the most widely used. It has five capability areas with four levels of maturity. Microsoft published SDL in 2008 and regularly updates it based on their growing experience and new industry trends.

Lessons Learned

At GlobalLogic, we’ve successfully implemented MS SDL in multiple projects, improving the overall security of the related software. Our point of view and takeaways based on the experience we gained from these projects include the following:

It’s Challenging To Get Started

Starting with the SDL can be complex and overwhelming. Teams struggle to implement the basics of SDL mainly because the outcome is challenging to measure at the beginning. Our recommendation is not to fall into the trap of the immediate value add, but to keep following the best practices and have patience.

Plan incremental goals rather than trying to achieve too many things at once. It helps to assess the baseline of the current state so that improvements can be measured.

Avoiding Focusing Only On Security Hygiene

Most of the team only focus on security hygiene (such as OWASP Tops 10) and consider software secure if it takes care of these. But software security goes beyond this. A team must focus on security functionality and ask how a functionality will impact the security; for example, the account lock functionality in case of three or more incorrect login attempts. Some of these can be standard or generic, while others require analysis from the hacker perspective.

Consistency is Key

Security is a continuous process and the team must be consistent in whatever they implement. Do not fall into the trap of one-time achievement mode, as it will create a false sense of security.

Consider the Organization’s Risk Appetite

Not all security risks are equal and not all applications have the same risks. The team must understand the organization’s risk appetite and should try to take care of risk accordingly.

Defined Roles and Responsibilities Help

When most of the team is focused on processes and tools for security, they can miss the importance of roles and responsibilities. It is essential to define clear security roles and responsibilities such as who is the security champion, who is responsible for fixing the security bug, etc.

Skills Training is Ongoing

Make sure that your team understands security and has the required skills. If not, have a strong training plan to bridge the gap. We have seen many teams fail in implementing SDL because of a lack of skills.

Conclusion

These are some of the key learnings and takeaways based on our experience. We will be publishing detailed implementation steps in future papers to help you start and mature your Secure Development Lifecycle.