Secure Software Development Lifecycle (SDLC): Key Phases Guide

Development teams already work in a very methodical repeating process – the Software Development Lifecycle (SDLC) – and a huge opportunity exists to infuse better security within it through a combination of awareness, activities, and workflows such that the outcome would be far more secure software. That is the Secure SDLC (SSDLC).

Software is eating the world, and software requires a behind-the-scenes factory that builds it. It’s hard to overstress the importance of security in software development today since applications are hacked daily with constantly changing tactics, and security and development leaders need solutions and methodologies to minimize the risks.

This blog will guide you through the implementation of a set of SSDLC methodologies aiming to incorporate security directly within the Software Development Lifecycle.

Why You Should Convert Your SDLC to SSDLC

Nearly half of security breaches are rooted in code. But the other half of the attack surface posed by software is huge – APIs, open-source libraries, application infrastructure, and more. Modern developments such as cloud and microservices have increased that attack surface even further, as well as growing dependencies on external software libraries and third-party components.

In the past, traditional software testing caught problems after development in dedicated testing activities. But this is now widely viewed as insufficient. It’s also an inefficient approach because:

• It is more time-consuming to catch a vulnerability after it was built because of the need to pause or disrupt the ongoing software development cycle.
• Some problems rooted in the architecture or in the code are harder to track after they are built. For example, suppose an internal API was exposed by mistake. Will a testing tool be able to find it without prior knowledge?

For those reasons, it is agreed industry-wide that information security should be integrated within the development lifecycle. In other words – turning it into a Secure Software Development Lifecycle – called SSDLC or SDL (Secure Development Lifecycle) for short.

Engineers are at the heart of software creation and therefore should also be further encouraged and empowered to build it securely. It has been proven again and again that good hygiene and security practices during software development will immensely reduce the overall risk and allow your organization to ensure the integrity of every software release.

A Step-By-Step Guide to the Secure Software Development Process

The journey for creating an SSDLC begins with a model. We will use the 5-step model commonly seen in the industry which breaks down SSDLC into 5 phases:

• Requirement – Gathering the scope of the feature(s) or product.
• Design – Technical design of the requirements.
• Development – Writing the code that implements the design.
• Testing - Verifying that the functionality works as expected.
• Deployment and Maintenance – Releasing the functionality and continuously supporting it.

Traditional security testing was done on steps (4) and (5) as an activity before and after production software release. For modern software development, it is important to embed security into each of these 5 steps.

The Requirements Phase

The key concept here is to set the tone and define the security aspects of the upcoming product or product feature. It is an important opportunity to drive a “security first” mindset and promote developer awareness.

For example – a new notification service is being drafted which would notify customers on important events. Security requirements should include, for example, separating tenants such that a notification will never reach the “wrong” customer. Also – will notifications ever contain sensitive data? If so, this introducing a range of security and privacy concern that must be accommodated.

The goal in this phase should be to create a “threat model” that will be used during the entire development lifecycle of the product or feature. This model should be based on security best practices, such as the one that OWASP defines.

The threat model should be the basis of its own requirements sessions. A good recommended first step is to schedule such a requirements session using a generic threat model as a template. Within that meeting – define the principles and guidelines to be used during development and testing – what is key to secure? What are the security best practices? It should also define all security controls that should be implemented as part of the development lifecycle.

Another option to consider – require a threat modeling and design meeting prior to scheduling a feature to be part of the sprint and explicitly define who can approve the threat model.

The Design Phase

Usually, engineering teams create the technical design of a feature. In our notification service example, there might be a new microservice, a message queue, a database to store undelivered notifications, etc. In this phase you must verify that the security design addresses the threat model generated in the requirements phase.

This is where security mechanisms are defined within the design. Key steps include:

• Review the security requirements.
• Identify, through brainstorming, weaknesses and possible design flaws. Use an “attacker” mindset to find weaknesses.
• Assess the different risks using threat modeling techniques – rank them by the severity and probability of the risk.

Development teams will ask for prioritization, and it is essential to come up with the absolutely non-acceptable risk, and the list of items where the risk can be accepted or reduced later.

The Coding Phase

Embedding security into coding means developers write safe code, eliminate security risks while coding, and do this before they submit their final version for further testing and deployment. To do this, several things need to be considered:

• Awareness and security mindset – training and education would significantly raise the bar. There are many people that interact with code changes, and having constant training and awareness will help catch anti-patterns and dangers such as data sanitization, communication encryption, and more. OWASP provides many useful training resources and as a first step understanding the OWASP Top 10 Security Risks is a must.
• Code Scanning – there are plenty of code analysis scanners that can catch problems as they are being coded. This includes SAST tools and SCA solutions that focus on libraries with open-source vulnerabilities. For many infrastructure declaration languages, there is a specific type of scanner called “Infra-as-Code” scanners, or IaC for short, that can detect insecure configurations. It is important to map the set of technologies being used with the available set of scanners in your organization.
• Build a Repeatable Process – create an operational process implementing both points above. For example, have developers run the security scanning tools before they submit their code and also schedule periodic training refreshers for security best practices. One option for integrating security scanning in the process leverages source-code-management systems (like GitHub) that use “pull requests” where developers must submit code for a merge, but the change must first pass a series of checks before approval. This can require a mandatory SAST scan with specifically designated individuals who are authorized to overrule a bad result.

The Testing Phase

This phase is a bit tricky. Having a true agile SDLC means there is no linear process where everything stops and only testing occurs. Most teams today build some sort of CI/CD pipeline where Continuous Integration occurs, and software is constantly tested.
In this model, there are a series of tests occurring at multiple stages. Some during coding, some after every code submission, some nightly, and some testing the live production environment.

Within the requirement stage, it is important to map where security tests should run. Previously we mentioned tests during the coding phase. But it is possible to introduce additional tests before deployment – it all depends on your release strategy.

To sum up, two key areas are important for this phase:

• Decide on which tests you need and where based on your release strategy.
• Implement those tests, preferably in an automated fashion so feedback would reach the developer as soon as possible.

There are many other security testing tools available that we didn’t cover in this short blog. To see a comparison of all available security tools and techniques, visit this page.

The Release Phase

In this phase, it is all about having a response plan and being one step ahead of attacks. You need to build the processes that allow you to A) be alerted if a new external risk becomes known, and B) stay on top of emerging security attacks, trends and solutions.

• Look for external risks – processes like penetration tests are important. They will catch risks that might have slipped through all previous security gates. Perform them periodically to maximize the chance of finding them.
• Handle alerts – some tools will provide you with threat intel that comes from new disclosures. For example, the log4shell vulnerability had been around in production, but once the vulnerability had been fully recognized, SCA tools alerted their users and security teams to quickly block and remove the vulnerable components. You must assume there are “0-day” vulnerabilities lurking in your apps too that could be discovered at any moment.
• Stay on top of security trends and technologies - It’s an ongoing arms race between security professionals and cybercriminals. The security community publishes new threat models and there is constant innovation in the security tooling and techniques.

Summary – Modernize and Secure your SDLC

It is time for everyone to hop on the SSDLC wagon. Two colliding trends require this call to action: the first is the growing threat of security breaches, and the second is the modernization of the application development lifecycle.

To have an effective security program, you must start implementing security in EVERY step of the SDLC, not just at the end of it. Fortunately, there is a lot of knowledge available to help, and several easy-to-use and cost-effective actions you can take to get started. And the advantages of implementing an SSDLC are worth it. By doing so you can achieve benefits such as a comprehensive view of your SDLC, the ability to continuously monitor your security posture, and gain valuable context and business critical insights on applications from code-to-cloud. 

Remember that it will be an incremental process and that every step along the way will be beneficial. One effective approach to start or boost your secure SDLC, is to have a complete mapping of your development environment – all assets, users, scanners and automations. Legit Security helps with consolidating this inventory and getting actionable insights to solidify security across your broader SSDLC environment.

If you'd like to see a complete map of your SDLC and start your journey toward an SSDLC, request a demo of the Legit Security Platform today!