Cycle de vie du développement logiciel sécurisé (SSDLC) – pourquoi est-il 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.

Lorsque l'accent est autant mis sur la productivité, les livraisons fréquentes et les délais serrés, le risque d'incidents de cybersécurité peut augmenter. Cybersécurité 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.

Qu'est-ce que le cycle de vie du développement logiciel (SDLC) ?

Le cycle de vie du développement logiciel (SDLC) est une approche structurée du développement logiciel, divisée en plusieurs phases. Généralement, le SDLC comprend les phases suivantes :

Exigences

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.

De plus, il est essentiel d'intégrer les considérations de sécurité dès la phase d'analyse des exigences afin d'identifier et d'atténuer les vulnérabilités potentielles, garantissant ainsi que le logiciel est développé avec un accent sur la sécurité et la conformité.

Design

Deuxièmement, nous devons transformer nos exigences en une conception technique. Nous recueillons des informations telles que : l'architecture d'une solution et la technologie utilisée (frontend, backend).

Mise en œuvre

Troisièmement, vient la phase de mise en œuvre. Cela signifie que nous mettons réellement en œuvre (développons) notre solution. Nous pouvons utiliser différentes méthodes de processus, du cycle en V aux approches agiles plus modernes.

Tests

Cette phase est importante. Nous nous concentrons désormais sur les tests (c'est-à-dire unitaires, d'intégration, fonctionnels). Il est crucial de vérifier si notre solution fonctionne et de combler les lacunes.

Déploiement et maintenance

Après les tests, nous déployons notre solution sur l'environnement cible. Enfin et surtout, nous devons maintenir notre solution, appliquer des correctifs, ajouter de nouvelles fonctionnalités si nécessaire, ou toute modification requise.

Cycle de vie du développement logiciel sécurisé – quels sont les composants ?

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.

L'objectif ultime du SSDLC est d'identifier les vulnérabilités dans le processus selon le principe du « shift left », qui souligne que plus tôt nous les identifions, moins la remédiation sera coûteuse.

L'intégration des objectifs de sécurité

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.

Modélisation des menaces

Après l'intégration des objectifs de sécurité, nous devons nous occuper demodélisation des menaces. 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.

Évaluations des risques

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.

Revue de code, 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.

Évaluations des vulnérabilités

Enfin, notre produit est prêt et implémenté dans l'environnement de développement. Il est temps de le tester. De nombreux tests peuvent être appliqués ici, lesquels ont été abordés dans la section SDLC.

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.

Tests d'intrusion

C'est la cerise sur le gâteau du SSDLC. Les tests d'intrusion sont un ensemble d'activités réalisées par untesteur d'intrusion. 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.

Surveillance

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.

Cybersécurité – pourquoi est-ce important ?

One of the key cybersecurity 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, with many phases, complexity and often strong time pressures, introduces 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.

Contactez-nous via le formulaire ci-dessous pour découvrir comment améliorer la cybersécurité au sein de votre organisation.

FAQ