Secure Software Development Lifecycle (SSDLC) – why is it important?

Understandably, productivity is an essential factor in the software development industry. Companies have to be flexible to keep up with the demanding market and new requirements from their customers. Nevertheless, we should keep in mind that the general rule of cyber security is that the lack of due care will result in an increased risk of cyber security incidents occurring. Software development is no exception to the rule.

When there is so much focus on productivity, frequent releases, and tight deadlines, the risk of cyber security incidents may increase. Cybersecurity may be omitted or not considered as one of the most important factors in a Software Development Lifecycle (SDLC). Often there is no security at all in SDLC or it is limited only to penetration testing. With this in mind, it is good to highlight what SDLC is and what areas it contains.

Integrating security into the software development process through a Secure Software Development Life Cycle (SSDLC) is crucial. The SSDLC framework ensures that security is embedded in every phase of development, from initial design to deployment and maintenance. This ongoing process includes continuous monitoring and improvement to adapt to evolving security threats, as well as proactive measures such as threat modeling and security testing throughout the entire development process.

What is Software Development Lifecycle (SDLC)?

Software Development Lifecycle (SDLC) is a structured approach to software development, which is divided into several phases. Typically SDLC contains the following phases:

Requirements

Firstly the question “what has to be developed?” must be considered. The answer to this question must be transformed into a set of functional and non-functional requirements.  After that, we need to consider what the software needs to meet the required functionality.

Additionally, it is crucial to integrate security considerations early in the requirements phase to identify and mitigate potential vulnerabilities, ensuring the software is developed with a focus on security and compliance.

Design

Secondly, we have to transform our requirements into a technical design. We collect information such as: a solution’s architecture and technology used (frontend, backend).

Implementation

Thirdly, the implementation phase comes. That means we are actually implementing (developing) our solution. We may use different process methods starting from waterfall to more modern, agile approaches.

Testing

This phase is important. Now we are focusing on tests (i.e. unit, integration, functional). It’s crucial to check whether our solution works and improve the gaps.

Deployment and maintenance

After the tests we deploy our solution on the target environment. Last but not least, we should maintain our solution, apply patches, add new functionalities if required, or any necessary changes.

Secure Software Development Lifecycle – what are the components?

We know what SDLC is. Now it is time to add cyber security to it. Secure Software Development Lifecycle (SSDLC) is a set of cyber security measures applied to the development process to ensure that our software is checked to identify vulnerabilities across multiple phases.

The ultimate goal of SSDLC is to identify vulnerabilities in the process following the “shift left” principle, which highlights that the sooner we identify them, the less costly the remediation will be.

The Integration of security goals

First of all, we start with blending cyber security into SDLC. This part should not be skipped as this is the point where potential changes in our software may be cheap to implement. There may also be situations where cyber security should play a crucial role, considering the risk of a particular requirement. For example, when the customer wants anonymous access to the FTP server, which is not the best idea from the cybersecurity perspective – it may be a good idea to advise the client and check if there are potential solutions or workarounds to be implemented to mitigate the risk.

Threat modelling

After security goals integration, we need to take care of threat modelling. This activity contains a set of actions to identify vulnerabilities before the start of the development work phase. During this phase, a security architect will assess our solution’s architecture, communication, components used, versions of modules etc. They will then map typical threats to check if there are actual vulnerabilities and where they may be and how they may be exploited by adversaries. Identifying and mitigating security risks throughout the software development process is crucial for protecting sensitive data and ensuring compliance with regulations.

MS Threat modelling tool example

Risk assessments

When the threat modelling is done, we need to define what kind of risks may occur and propose some mitigations. Risk assessments may be qualitative. We assess them based on our expert knowledge, benchmarks, the criticality of assets and many more. Another option is to choose a quantitative risk analysis. To do that, we add monetary value to our key assets and calculate a risk score. The final product for both approaches is a risk register. It will contain all identified risks, a risk score, mitigation techniques and other recommendations for the cyber security team.

Code review, SAST (Static Application Security Testing)

The development phase is ongoing. Therefore, we need more hands. The goal of this work is to blend the security requirements into the development process. Development teams play a crucial role in integrating security practices during this phase. The most common testing methodologies are Static Application Security Testing (SAST) and code review.

SAST is usually embedded into the Software Development Toolkit (SDK) and is used to test the security flaws in the source code during development. They should be reviewed in the same way as the code itself by a skilled security analyst who can interpret the results and understand the wider picture of more complex vulnerabilities.

Vulnerability assessments

Finally, our product is ready and implemented in the development environment. It’s time to test it. There are plenty of tests which may be applied here which were covered in the SDLC section.

We should not forget about cyber security here as well. Now, we should further explore if there are vulnerabilities in our ‘almost final’ product. We may use tools which will automatically check if there are any vulnerabilities. For example, in Web applications, we provide login and password and the tool will login and automatically check if there are any typical vulnerabilities in forms, input fields etc.

Nowadays software contains lots of open source components. For small development activities, it may be manageable to identify and check what kind of open source components we use. For larger and enterprise-wide projects it may be a really tough nut to crack. The activity to identify if there are any open source components in our software is called Software Composition Analysis (SCA).

Fortunately, there are tools which support the identification of open source modules and vulnerabilities identification. Additionally, they provide information about licenses required for every single component. After that, the results are presented to an analyst as a Bill of Materials (BOM) and they may be reviewed and be a good input to support the decision if a specific component should be removed, changed or accepted.

Penetration Testing

This is the cherry on the top of SSDLC. Penetration testing is a set of activities performed by a pentester. The ultimate goal of their activity is to mimic real hacker activities to identify and exploit vulnerabilities in our software. Penetration testing is a structured activity and considering the tight time frame of typical engagement, we may expect that pentesters will follow some of the most popular frameworks such as OWASP to identify the most common vulnerabilities (low hanging fruits). The result of the pentesting activity is a comprehensive report which contains all findings with evidence and proposed mitigation.

Sample from Penetration testing report

Monitoring

Organisations should keep in mind that handing over the product is not the end of the process. Some form of monitoring should be in place. It’s good to ensure that pentesters check the software regularly, especially when new functionalities are introduced. It then should fall under the vulnerability management process to deal with identified vulnerabilities and patch management as well to handle the patching process. Secure development is in opposition to the “deploy and forget” approach and we should use this approach, especially when new vulnerabilities for existing components are identified every day.

Cybersecurity – why is it important?

One of the key cyber security principles is “cybersecurity is as strong as the weakest link in the chain”. This quote perfectly fits the SDLC approach, because the nature of the process, many phases, complexity and often strong time pressures, introduce the risk of omitting some key cyber activities which later may be a big issue for the organisation which develops software. Blending cybersecurity into SDLC is more crucial than ever nowadays and organisations should consider implementing if not all, at least some parts of the process to protect code repositories and develop secure software.

Contact us using the form below to find out how you can improve cybersecurity in your organisation.