Secure Software Development Lifecycle (SSDLC)

Introduction

Application security is one of the most critical elements in today's rapidly evolving world of technology. Security failures are associated with financial losses and loss of customer trust. Almost every day we hear about major breaches, hacks, or attacks on applications and IT systems, resulting in theft or loss of data or service interruptions. To protect yourself and avoid security gaps, security issues must play a significant role in the entire application development process.

The Secure Software Development Lifecycle ( SSDLC , S-SDLC , or Secure-SDLC ) introduces security elements into the traditional software development process ( SDLC ). The process spans all stages of software development, providing a comprehensive approach to security at every step. To understand which security elements are included, let's first look at what the traditional SDLC approach looks like.

SDLC Process

Software Development Lifecycle (SDLC) is a systematic process aimed at delivering a software product (or, in a broader sense, an IT system) in an effective, economically efficient manner that meets the expectations of the customer and end user.

This process consists of several stages:

1. Requirements collection and analysis - the first stage, the purpose of which is to obtain the necessary information regarding the purpose and scope of the project and the requirements and expectations of the client. It is at this stage, based on discussions with clients, end users and on the analysis of the market and current solutions, that the main framework and design assumptions are determined.

2. Design - at this stage, it is determined how the project will be implemented. A solution specification is created, including its architecture, technologies, and required resources. A project roadmap is written, task priorities are set, and project risks are assessed. On the basis of the prepared project, the method of its implementation is determined.

3. Implementation - at this stage, the project is started and software is created based on the specification. The source code is written, the infrastructure is created, the integration and delivery pipeline (CI/CD pipeline) is built. At this stage, dependencies to external libraries (3rd party) are also created and the supply chain is built.

4. Testing - the purpose of this stage is primarily to verify whether the software delivered in the implementation phase meets business and design requirements, and above all, whether it meets customer expectations. Non-functional elements of the software, such as performance, stability, and security, are also tested.

5. Release - at this stage, the finished solution (or part of it), after passing functional and non-functional tests and, above all, after acceptance by the customer, is implemented in the production environment to be finally made available to end users.

6. Maintenance - is a stage that provides support for the implemented software. At this stage, updates, fixes, and functional extensions are provided.

Depending on the chosen methodology, stages 3-5 can occur in a cascade, so that the next one starts only after the previous one is completed (Waterfall), and the full solution is delivered to the customer only at the end, after the work is completed. Or, as is the case with agile methodologies, when individual parts of the solution are delivered on an ongoing basis, in a cyclical manner, in short iterations.

Process Issues in the Context of Security

The main goal of the traditional SDLC process is to ensure that the product meets functional requirements first and foremost, that it is useful to the end user, and that its development fits into the appropriate time and budget. Of course, security issues arise during the process, but this occurs mainly in the testing phase, when non-functional elements are taken into account.

Unfortunately, this results from the fact that security is often treated as an add-on and is not an integral part of the other aspects of the designed system. Functionality and usability are usually at the forefront, as well as finding the right balance between them. However, in terms of security, the statement: "and let it be safe" will often be enough for the client. In the design phase, in the specification, it comes down to "introducing standard security" or "implementation in accordance with standards" (whatever these phrases mean). Programming teams, often insufficiently trained in security, focus on delivering primarily the main functionalities, having a tight schedule and being traditionally short of time, superficially treating or completely omitting security issues. And it is only in the testing phase, when testers get to security tests, that it turns out that there is a problem. And sometimes, in an even worse case, vulnerabilities come to light only in the maintenance phase.

Detecting errors too late prevents them from being repaired easily, effectively and cheaply.

The well-known principle of the relative cost of fixing defects [Figure 1] shows that this cost can increase even hundred-fold if the bug is not identified in time.

Fig. 1. Relative cost of fixing defects

SSDLC solution

SSDLC integrates security practices into every stage of the software development process, assigning specific application security goals and tasks to each stage. So let's take a look at the individual phases and practices that this secure equivalent of the traditional SDLC cycle introduces:

1. Gathering and analyzing requirements - at this stage, the risk asessment plays a key role, which must take into account threats related to cybersecurity. In a business context, with properly defined risks, you can specify security requirements and appropriate policies that must be met by the application.

2. Design - at this stage, security policies are integrated with the project. Threat modeling is performed and, on this basis, appropriate countermeasure techniques are implemented in the project, such as data encryption, access control, network security, etc. At the end of the design stage, a security review of the system architecture and the prepared specification should be performed.

3. Implementation – In this phase, the most important aspect of security is adhering to secure coding practices. Security considerations must be incorporated at every step dedicated to ensuring code quality. This includes coding guidelines, which should integrate security best practices, code reviews, conducted during code changes to identify potential security issues, and static application security testing (SAST). Additionally, software composition analysis (SCA) tools should be used to assess the security of external libraries, ensuring the the software supply chain is secured.

4. Testing - At this stage, the entire code and application can be tested as a whole. Dynamic analysis of the application security is performed using Dynamic Application Security Testing (DAST) tools. In addition to dynamic analysis, it is recommended that static analysis (SAST) with software dependencies scanning (SCA) are also performed by dedicated testing teams with knowledge of security. At this stage, penetration testing plays a very important role, which, together with vulnerability scans, will allow to identify security errors in the application before its implementation.

5. Production release -  in this phase, penetration testing should continue, focusing not only on the application itself but also on verifying the security of the entire platform, runtime environment, and network. This includes security reviews of the configuration of these components and implementing monitoring systems to oversee their security.

6. Maintenance - the maintenance phase requires constant care for security and constant monitoring of it in terms of logs and security events. Adding new functionalities opens up space for the emergence of new threats, therefore it is important to systematically and cyclically conduct security audits and tests, and in the event of detection of new gaps, proper vulnerability management and an appropriate update and patch policy.

Below is a summary of security practices for each phase of the SDLC:

Stage	Security practices
Requirements collection and analysis	- Risk assessment - Defining safety requirements - Creating a security policy
Design	- Threat modeling - Using appropriate design patterns - Architecture Security Review
Implementation	- Secure Coding Guidelines - Code Security Reviews - Static code analysis (SAST) - Software Composition Analysis (SCA)
Testing	- Dynamic Application Analysis (DAST) - Static Analysis (SAST) - Software Composition Analysis (SCA) - Penetration testing - Vulnerability Scans
Production release	- Penetration testing - Configuration Security Review - Security monitoring
Maintenance	- Security monitoring - Security audits - Vulnerability Management - Updates and security patches

Balance

Integrating security practices into every step of the software development cycle is a great example of using the shift-left strategy, i.e. taking into account security aspects as early as possible. This allows you to take these aspects into account at the stage of requirements analysis and design and balance them appropriately, together with functionality and usability. The well-known principle of interdependence between these elements says that nothing is free and there is always a cost to something. This is usually represented as an isosceles triangle with a representation of each of the elements at the vertex. The balance of requirements in the context of security, functionality and usability is presented as a point inside this triangle. The closer this point is to one of the vertices, the more attention we pay to that element and the more important it becomes. Unfortunately, the price is a decrease in the quality of the others.

Fig. 2. The triad of functionality - usability - security

A good example is accessing an account in an application (e.g. in a web service). The most convenient way would be to simply enter a username, but of course this method would provide almost no level of security. Therefore, we enter a password, which obviously worsens the convenience of the login process. Going further, introducing two-factor authentication (2FA - Two Factor Authentication) increases our security even more, but again this happens at the expense of convenience, i.e. usability.

We can therefore visually represent this on a triangle as a change in the position of a point relative to the appropriate vertices (the distance from the functionality vertex does not change, because functionally nothing changes - the user still gains access to his or her account during the login process):

Fig. 3. Changing the position of the functionality point with the introduction of safety elements.

The location of the point is of course conventional and it is only about the pictorial representation of the dependencies. Increasing security will always affect functionality and/or usability. That is why it is so important to consciously implement this security from the very beginning of the project, from the first phase, and take into account its cost in the context of the entire project.

End

Failure to properly address security aspects in IT systems and software may lead to negative image, financial and legal consequences.

In an era of constant cyber threats, implementing an SSDLC process is not only a necessity, but also a key element of a proactive approach to security and should be a foundation of every organization’s software development process.

If your company or organization is considering implementing SSDLC or needs support in improving existing security processes, please contact us.