Secure Software Development Life Cycle (SSDLC): What is it?

SDLC stands for Software Development Life Cycle. In plain words, SDLC is the framework that outlines how to reliably develop a quality piece of software. Development teams use it to keep a balance between costs, efficiency, and risks. S in S-SDLC stands for security. It represents a revised framework to embed security considerations and activities across all stages of the development cycle. 

In this post, we’ll outline how the shift from SDLC to SSDLC changes the software development life cycle. We’ll specify what security activities to include. We’ll also cover what it means from the standpoint of costs and development hours. 

Backstory to Security Trends

 Businesses of different sizes and domains treat the matter of security differently. Big corporations like Google, Microsoft, and others are the ones who push security concerns and standards forward. They have entire dedicated security departments.

Remember the times when website addresses stopped starting with “http…”? Now it is websites that start with “https…”. Now, if you go to HTTP without an s, a browser might even issue a warning that you are risking it. Overall, by 2019, HTTPS became a standard across all valid browsers like Google, Mozilla, and such. 

The other approach is for individual digital entrepreneurs, mid-size businesses, and even some large organizations. For them, security was a ‘have-to-do-it’ expense item. 

• Some organizations contracted out this to third-party contractors. 
• Some hired a few security specialists. In general, security was a thing to cut corners. 

After all, business goals are always about reaching functional products faster. So, the topic of security was rarely popular. 

However, S-SDLC came to change things. Businesses now need security. Why?

1. The digital business world has been booming and the speed of releasing new apps skyrocketed. All of it happened not without sacrifices. Many businesses focused on just-in-time practices. It was quite reasonable to delay security considerations until the time was right.
2. Security concerns became a hot topic after the Covid-fueled rush into the digital world. Customers, governments, and business people changed their outlook on security. 

Does any of it reflect in numbers? Yes, indeed!

Just a bit of statistics (as of year 2021 data):

• 88% of users care about how secure your app is. It is to the point they will not use services if they are not secure;
• 38% of users will never come back. It is after the news of the data breach or if there is information about misusing users’ data.

And a bit earlier (2020) study revealed that business owners grossly underestimate the value of security for their users. 85% of the surveyed users said that there was a market gap: not enough secure companies. 83% said they wanted control over their data. 

So, imagine how businesses complain about high competition and saturated markets. At the same time, users say that there is little to nothing to choose from. Users do see the market as half-empty to underplay it. That’s why it is high time to incorporate security making a marketable advantage of it now.

What S-security activities are Now Part of SDLC?

Traditional SDLC consists of these 5 phases:

1. Planning: requirement gathering;
2. Designing: architecture and prototyping;
3. Development: coding;
4. Testing;
5. Launch and Maintenance.

Security activities expand each of these stages now. Some of them are mandatory and some are optional. As we’ve mentioned, the scope of the project and its goals is a yardstick to see which security features to implement. 

You can check Startup Lifecycle Stages to see how this concept works In modern start-up development agencies. And to accompany this knowledge, here are Lean Startup Circle Tips.

Planning: requirement gathering

This is the fundamental stage of the software development life cycle. It includes researching of market, studying the customers, and assessing the opportunities and risks. Then, the project feasibility study uses this knowledge. It is to assess the long-term and short-term prognosis for the project.

Usually, the result of this stage is the technical requirement document. Senior team members verify it and develop software requirement specifications (SRS). 

Security activities of the secure software development life cycle ask to add at least one of the following.

Vulnerability analysis 

It includes asking things like: Is your authentication mechanism strong enough? Can it lead to unauthorized control/access? Imagine IoT applications like smart homes. What if somebody hacks in and controls your user’s installed devices? 

Vulnerability analysis includes:

– threat identification, 

– risk analysis, 

– tools to test, and 

– repeat activities in case of significant feature updates or releases.

Pentesting 

This is when a cybersecurity specialist simulates cybersecurity attacks on your app to see where it is vulnerable. 

For an e-commerce app, the common threats are:

• SQL injections, 
• cross-site scripting attacks (XXS), or 
• exploiting the file upload point.

Threat modeling 

This requires modeling the app’s assets and resources. Then the team lists all possible threats to these resources. The next step is to propose mitigation strategies. 

For example, in SaaS applications, malicious users can intercept data. To mitigate this, we need to implement HTTPS protocols to encrypt data in transit.

Code analysis

Developers can do it manually or with tools. 

There is a static and dynamic code analysis. 

Static code analysis is when developers check the codebase against the CVE security vulnerability database. 

For instance, SonarQube is one such free tool that performs static checks. But you still need a person who will:

– set up code analysis, 

– carry it out, 

– interpret results, and 

– formulate recommendations.

White/Grey/Black-Box Testing

White testing means the tester knows the workings of the inner system. 

Grey testing means the tester knows some parts of the application code. 

Black-box testing means the tester knows nothing of the codebase. 

For example, let’s discuss e-commerce grey testing. A tester can check the codebase for forms (part of the code). Then, they will try to manipulate input fields on the client side. This is to check for the possibility of tampering with user data and detecting vulnerable entry points.

Designing: architecture and prototyping

Ideally, after the planning stage, a few architectures/designs are possible for implementation. Al major stakeholders assess these. The assessment includes different criteria but now security is among them. 

For smallish and less complex projects, we’ll be talking about a feature set rather than assessing architectures. Each feature gets a rating:

– the complexity of development (time and money), 

– impact on the bottom line, and 

– security. 

Security considerations can significantly alter the course of product design. For example, if this is an e-commerce store, user authentication is a standard feature. This way customer have their profiles with their data like:

– purchase history, 

– delivery address, 

– viewed items, 

– liked items etc. 

Yet, secure user authentication adds to the project timeline. 

On the other hand, what if we drop this feature altogether? Allow users to browse the store, add items to the shopping cart, and do a guest checkout. Lean startup methodology focused on MVP or MMP would certainly favor this design decision.

 Later, when developing a full-scale app, the secure user authentication feature can become a priority.

Development: coding

Once planning, designing, and prototyping finished, the developers code up the required application. It’s no secret that there are always shortcuts. Or as developers say a custom library of reusable code modules. These shortcuts allow them to cut development hours and offer more attractive rates to clients.  

• However, S-SDLC will not favor this approach. 
• All modern languages evolve to incorporate higher levels of code security. 
• Secure coding practices are different from simply coding. 
• Old reusable libraries won’t do anymore. 
• Developers need to revise, update, replace, and sometimes plainly code from scratch. 

A big part of secure coding is hiding variables, and limiting access to variables, functions, and such. Yet, a bigger focus is on the validation of the data. The one that comes from the user, API, or database. 

One of the cybersecurity principles is to restrict invalid requests. That is if the application doesn’t a particular request or endpoint, a developer must explicitly code it.

For instance, there is HTTP patch and put requests. They are similar but each project implements one of them.  

Previously, a developer wouldn’t care about processing a patch request if put request was in technical specification. However, now this patch request must send a specific error message. Plus, it is better to log such an attempt. This way back-end APIs and microservices become more secure. 

There is also a whole set of practices to manage application behavior in response to misconfiguration.

Testing

Testing is a whole other chapter. 

• In big projects, there might be testing teams that have their own testing plans, cases, scenarios, and tools. 
• In addition, each developer is responsible for their own unit testing. 
• Plus, teams perform functional testing. 
• Other kinds are also possible but they will mostly focus on usability testing. Checking how well the application performs following different user scenarios, different device configurations, and environment variables. 

In S-SDLC, the testing for security purposes is a separate activity. It should follow the defined guidelines lined up during stages of planning and architecture design. 

Launch and Maintenance

Launch and maintenance are as important stages as all previous ones. 

Many companies choose to do step-by-step launches whereby they limit the audiences that see the product. They get feedback and improve. Then launch again to a wider circle. 

Such an iterative launch allows you to manage your app’s market acceptance and fine-tune the final product. 

SSDLC in costs and development hours

SDLC is a concept, and it finds implementation through different methodologies. For example, the two big ones are waterfall and agile. 

Agile takes SDLC as a core concept and then modifies it to meet specific requirements. In terms of Agile, the most famous modifications are Kanban, SCRUM, Lean, Microsoft SDL, or SECDEVOPS. 

Microsoft and SECDEVOPS are the most thorough and centered around security. Yet, they are suitable for big development projects. Large tech companies use these. But for others, implementing every rule in the book is wasteful and lacks a sense of purpose. 

Smaller size projects and commercial businesses follow SCRUM, Kanban or Lean methodologies. In pure SDLC implementation:

• SCRUM doesn’t outline explicitly any specific security activities. It encourages each individual to do their best in this respect;
• Kanban encourages the team to view security as a factor in their work. It includes security-related tasks and SLAs. 
• Lean ensures security from the standpoint of integrity. Their focus is on the integrity of data flow and access to that data. It usually includes preventing data breaches or unauthorized access.

To follow S-SDLC framework, there is a need to hire an extra specialist. 

• In Scrum, like there is a SCRUM master, there should be a security master.
• In Kanban and Lean, a security specialist must join the team. It doesn’t always mean a full-project dedication kind of commitment. It depends on the project, its size, complexity, and nature. 

Code review meetings is where this security specialist will be especially important. And, of course, the planning stage when it is time to select security activities for the entire project.

The cost can also vary. From $30 to $90 per hour depending on the level of specialist. Sometimes it can be up to 10 hours of well-qualified security consultant, amounting to $900. Sometimes it might be a full onboarding of a certified security specialist.  

Just bear in mind, that when a security breach happens or a system crashes, the whole team partakes in fixing it. That will include:

• Analyzing errors and data leaks and going over logs. 
• All developers will have to analyze possible sources of vulnerabilities. 
• ll coding teams will be incurring extra hours. 

In short, prevention is often cheaper than redemption. Especially, with modern users. 

Secure SDLC often pays off by not spending on fixing. Plus, factor in losses from losing users after security issues. This is actually how to form a security budget. A percentage of estimated development hours and potential client loss. 

We would also recommend reading the following articles:

• Startup Requirement Document: SRD, PRD, MRD

FAQ – Secure Software Development Life Cycle:

Summing Up

For sure, S in SDLC will come at some cost. But everyone is still looking this way now. This is because now it pays off. 

First, secure digital products are a free open niche in many industries. 

Second, fixing vulnerabilities after the security breach is not much cheaper. After all, taking a secure approach from the get-go pays off. Just calculate how much you spend on security versus how much you would have had to spend on fixing things.