Cycle de vie du développement logiciel sécurisé (SSDLC)

La sécurité est un élément essentiel de toute application qui englobe des fonctionnalités critiques. Il peut s’agir de protéger une base de données contre les attaques d’acteurs malveillants, ou d’appliquer un processus de détection des fraudes à un prospect qualifié avant de l’importer sur votre plateforme.

Phases du SDLC

Le cycle de vie du développement logiciel (SDLC) décrit la manière dont les applications logicielles sont créées. Il comprend généralement les phases suivantes :

• Collecte des exigences

• Analyse des exigences pour orienter la conception

• Conception de nouvelles fonctionnalités en fonction des exigences

• Développement de nouvelles capacités (écriture de code pour répondre aux exigences)

• Test et vérification des nouvelles capacités : confirmer qu’elles répondent bien aux exigences

• Déploiement du nouveau projet

Maintenance et évolution de ces capacités après la mise en production

Les 7 phases du cycle de vie du développement logiciel

Méthodologies SDLC :

Développement agile :

Le développement agile selon le SDLC préconise de diviser les grandes versions monolithiques en plusieurs petites versions, chacune réalisée au cours de sprints de deux ou trois semaines, et de recourir à l’automatisation pour créer et vérifier les applications. Les entreprises peuvent ainsi itérer beaucoup plus rapidement. Au lieu des déploiements monolithiques peu fréquents des applications développées selon le modèle en cascade, le développement agile vise souvent à publier de nouvelles fonctionnalités plusieurs fois par jour et à créer les logiciels progressivement plutôt qu’en une seule fois.

Développement en cascade :

Le modèle SDLC en cascade est l’une des premières méthodologies SDLC et l’une des plus connues. Il a posé les bases des phases du SDLC. Définies en 1970, ces phases restent en grande partie les mêmes aujourd’hui, mais les pratiques d’ingénierie logicielle ont considérablement évolué, redéfinissant la manière dont les logiciels sont créés.

Pourquoi le SDLC sécurisé est-il important ?

La sécurité s’applique à chaque phase du cycle de vie du développement logiciel (SDLC) et doit rester une priorité pour vos développeurs lorsqu’ils mettent en œuvre les exigences de votre logiciel. Avec des efforts ciblés et les bonnes solutions de sécurité SDLC, il est possible de traiter les problèmes de sécurité dans le pipeline SDLC bien avant le déploiement en production. Vous réduisez ainsi le risque de découvrir des vulnérabilités de sécurité dans votre application et limitez leur impact si elles sont détectées.

L’objectif du SDLC sécurisé n’est pas d’éliminer complètement les contrôles de sécurité traditionnels, comme les tests d’intrusion, mais plutôt d’intégrer la sécurité aux responsabilités des développeurs et de leur donner les moyens de créer des applications sécurisées dès le départ.

SDLC et sécurité des applications

 La correction d’un problème découvert aussi tard dans le SDLC peut coûter jusqu’à 100 fois plus cher que s’il avait été corrigé dès le début du processus 

En intégrant des mesures de sécurité dès le début du SDLC, les développeurs peuvent identifier et traiter de manière proactive les problèmes de sécurité potentiels, réduisant considérablement le coût de correction des vulnérabilités à un stade ultérieur du développement. 

Quels sont les processus du cycle de vie du développement logiciel sécurisé ?

La mise en œuvre de la sécurité SDLC concerne chaque phase du processus de développement logiciel. Cette approche est bien plus efficace et beaucoup moins coûteuse que d’attendre que les problèmes de sécurité se manifestent dans l’application déployée. Les processus de développement logiciel sécurisé intègrent la sécurité à chaque phase du SDLC.

Intégrer la sécurité à chaque phase du SDLC relève avant tout d’un état d’esprit que chacun doit adopter. Toutefois, les considérations et les tâches de sécurité associées varient considérablement selon la phase du SDLC.

5 phases du cycle de vie du développement logiciel sécurisé

Chaque phase du SDLC doit contribuer à la sécurité globale de l’application. La manière de procéder varie selon la phase, mais un point essentiel demeure : la sécurité du cycle de vie du développement logiciel doit être une priorité pour toute l’équipe. Prenons l’exemple d’un cycle de développement logiciel sécurisé pour une équipe qui crée un portail de renouvellement d’adhésion :

Phase 1 : Exigences

Au cours de cette première phase, les exigences relatives aux nouvelles fonctionnalités sont recueillies auprès de différentes parties prenantes. Il est important de repérer les considérations de sécurité liées aux exigences fonctionnelles collectées pour la nouvelle version.

• Exemple d’exigence fonctionnelle : les utilisateurs doivent pouvoir vérifier leurs coordonnées avant de renouveler leur adhésion.

• Exemple de considération de sécurité : les utilisateurs ne doivent voir que leurs propres coordonnées, et celles de personne d’autre.

Phase 2 : Conception

Cette phase traduit les exigences retenues en un plan décrivant l’apparence de l’application et son fonctionnement. Les exigences fonctionnelles décrivent généralement ce qui doit se passer, tandis que les exigences de sécurité portent plutôt sur ce qui ne doit pas se produire.

• Exemple de conception fonctionnelle : la page doit récupérer le nom, l’adresse e-mail, le numéro de téléphone et l’adresse de l’utilisateur dans la table CUSTOMER_INFO de la base de données, puis les afficher à l’écran.

• Exemple de préoccupation liée à la sécurité : nous devons vérifier que l’utilisateur possède un jeton de session valide avant de récupérer des informations dans la base de données. En l’absence de jeton, l’utilisateur doit être redirigé vers la page de connexion.

Phase 3 : Développement

Lors de la mise en œuvre concrète de la conception, il faut généralement veiller à ce que le code soit bien écrit du point de vue de la sécurité. Des consignes de codage sécurisé sont généralement établies, et des revues de code permettent de vérifier qu’elles sont correctement suivies. Ces revues peuvent être manuelles ou automatisées à l’aide de solutions de tests de sécurité statiques des applications (SAST).

Cela dit, les développeurs d’applications modernes ne peuvent pas se préoccuper uniquement du code qu’ils écrivent, car la plupart des applications actuelles ne sont pas créées de zéro. Les développeurs s’appuient plutôt sur des fonctionnalités existantes, généralement fournies par des composants open source gratuits, pour livrer aussi rapidement que possible de nouvelles fonctionnalités et de la valeur à l’organisation. En fait, plus de 90 % des applications modernes déployées sont constituées de ces composants open source. Les outils d’analyse de la composition logicielle (SCA) vérifient généralement ces composants open source.

Voici quelques exemples de consignes de codage sécurisé :

• Utiliser des requêtes SQL paramétrées et en lecture seule pour extraire des données de la base de données et réduire le risque que quelqu’un détourne ces requêtes à des fins malveillantes

• Valider les entrées utilisateur avant de traiter les données qu’elles contiennent

• Assainir toutes les données renvoyées à l’utilisateur depuis la base de données

• Vérifier la présence de vulnérabilités dans les bibliothèques open source avant de les utiliser

Phase 4 : Vérification

Lors de la phase de vérification, les applications font l’objet d’une série complète de tests pour s’assurer qu’elles répondent aux exigences et à la conception initiales. C’est également le moment idéal pour introduire des tests de sécurité automatisés reposant sur différentes technologies. L’application n’est déployée que si ces tests sont réussis. Cette phase fait souvent appel à des outils automatisés, tels que les pipelines CI/CD, pour contrôler la vérification et la mise en production.

La vérification à cette phase peut inclure :

• Des tests automatisés couvrant les parcours critiques de votre application

• L’exécution automatisée de tests unitaires vérifiant le bon fonctionnement de l’application

• Des outils de déploiement automatisés qui injectent dynamiquement les secrets de l’application destinés à l’environnement de production

Phase 5 : Maintenance et évolution

L’histoire ne s’arrête pas une fois l’application publiée. Des vulnérabilités passées inaperçues peuvent être découvertes dans l’application bien après sa mise en production. Elles peuvent se trouver dans le code écrit par les développeurs, mais sont de plus en plus souvent présentes dans les composants open source sous-jacents. Les responsables de la maintenance des applications découvrent ainsi davantage de « vulnérabilités zero-day », jusque-là inconnues, en production.

L’équipe de développement doit alors corriger ces vulnérabilités, ce qui peut parfois nécessiter une réécriture importante des fonctionnalités de l’application. À ce stade, les vulnérabilités peuvent aussi provenir d’autres sources, comme des tests d’intrusion externes menés par des hackers éthiques ou des signalements du public dans le cadre de programmes de « bug bounty ». Il faut prévoir le traitement de ces problèmes en production et en tenir compte dans les versions futures.

Les avantages du SSDLC

Les principaux avantages du SDLC sécurisé sont les suivants :

• Réduction du risque de violation de données 

• Amélioration de la résilience des applications 

• Renforcement de la confiance des utilisateurs 

• Réduction des coûts de correction

Le SDLC sécurisé est l’exemple ultime d’une initiative de « shift left », qui consiste à intégrer les contrôles de sécurité le plus tôt possible dans le SDLC.

Cette approche aide les équipes de développement à bien planifier les versions et à détecter et résoudre plus facilement les problèmes susceptibles de compromettre le calendrier de publication. C’est préférable à une mauvaise surprise après le déploiement de l’application en production. Le SSDLC contribue donc au respect du calendrier des versions.

De plus, au cœur du SSDLC, les efforts en matière de sécurité sont pilotés par l’équipe de développement elle-même. Les experts qui ont écrit le logiciel peuvent ainsi corriger les problèmes, plutôt que de laisser une autre équipe réparer les bugs après coup. Les développeurs prennent en charge la qualité globale de leurs applications, ce qui permet de déployer des applications plus sécurisées en production.

Tous ces tests de sécurité supplémentaires dans le processus SDLC peuvent sembler fastidieux et coûteux à mettre en place, mais aujourd’hui, la plupart sont automatisés. C’est particulièrement vrai pour les opérations de développement, ou DevOps (nous y reviendrons ci-dessous). Un environnement SDLC sécurisé nécessite une collaboration fréquente entre les équipes DevOps et les ingénieurs qui implémentent les fonctionnalités de l’application. Cette collaboration doit être intégrée au SDLC lui-même.

En corrigeant ces problèmes dès le début du processus, les équipes de développement peuvent réduire le coût total de possession de leurs applications. Comme le montre le graphique ci-dessous, la découverte tardive de problèmes dans le SDLC peut multiplier par 100 le coût de développement nécessaire à leur correction.

IBM System Science Institute : coût relatif de correction des défauts, 2010

Comme le montre la figure 2 ci-dessus, le passage à un SDLC sécurisé permet aux équipes de développement de créer des applications sécurisées plus rapidement et peut donc constituer un investissement intéressant pour les organisations.

Comment garantir un SSDLC ?

Pour garantir un SDLC sécurisé, il faut s’intéresser au fonctionnement de l’application et à la manière dont les développeurs transforment les exigences en code. La sécurité doit rester une priorité pour toute l’équipe pendant le développement de l’application. Cela peut nécessiter un changement de culture au sein de vos équipes, ainsi que la mise en place de processus et de contrôles automatisés à chaque étape du développement logiciel.

La capacité à garantir un SSDLC pour une application dépend fortement des forces et des faiblesses de l’équipe de développement chargée de la sécurité SDLC. Il est donc difficile de définir un processus unique de SDLC sécurisé.

Comme le SDLC sécurisé implique de modifier les processus existants, de mettre en place de nouveaux outils et, surtout, de faire évoluer la culture de plusieurs équipes, le parcours vers un SDLC sécurisé et efficace est généralement propre à chaque organisation. Il peut même varier d’une unité opérationnelle à l’autre.

5 bonnes pratiques pour un SDLC sécurisé

1. Formez vos développeurs

Le SDLC sécurisé va de pair avec plusieurs initiatives connexes, notamment :

• La création de consignes de codage sécurisé

• La sensibilisation des développeurs à la sécurité et leur formation au codage sécurisé

• La définition d’attentes claires concernant les délais de résolution des problèmes découverts en production (également appelés SLA de correction).

Toutes ces mesures ne sont pas indispensables à une mise en œuvre efficace du SSDLC. Mais, comme pour un puzzle, vous devrez assembler suffisamment de pièces avant de pouvoir en voir l’ensemble.

2. Définir des exigences claires

Quel que soit le contenu que vous créez, il doit être facile à comprendre. Les équipes de développement ont besoin d’exigences claires, faciles à mettre en œuvre. Cela vaut pour tous les conseils, recommandations et directives en matière de sécurité. Les vulnérabilités découvertes lors des tests doivent être faciles à corriger. Il est essentiel que toutes les personnes, tous les processus et tous les outils concernés proposent des solutions au lieu de se contenter de signaler les problèmes.

3. Cultiver un état d’esprit axé sur la progression

Comme le SSDLC va modifier la façon dont plusieurs équipes travaillent et interagissent, il est important que chacun aborde cette démarche avec un esprit ouvert et que l’équipe de sécurité cherche à donner aux développeurs les moyens de sécuriser eux-mêmes leurs applications.

4. Associer la mise en œuvre à d’autres initiatives

Pour les applications et les équipes bien établies, il est souvent plus facile de mettre en œuvre les changements liés au SSDLC en les associant à un autre effort de modernisation, comme une migration vers le cloud, une initiative DevOps ou sa variante plus axée sur la sécurité, DevSecOps.

5. S’attaquer d’abord aux problèmes les plus importants

Concentrez-vous sur les problèmes les plus importants et les correctifs concrets plutôt que de chercher à corriger toutes les vulnérabilités découvertes. Les applications récentes ou de petite taille peuvent parfois corriger tous leurs problèmes de sécurité, mais cette approche ne convient pas nécessairement aux applications plus anciennes et plus volumineuses 

Une approche de triage peut également être utile. Elle vise non seulement à empêcher que des problèmes de sécurité n’atteignent la production, mais aussi à garantir que les vulnérabilités existantes sont évaluées et traitées au fil du temps.

SSDLC et DevSecOps

Bien que le SSDLC et DevSecOps soient étroitement liés, il s’agit en réalité de pratiques complémentaires. Tous deux visent à donner aux développeurs davantage de responsabilités sur leurs applications, en veillant à ce qu’ils ne se contentent pas d’écrire et de tester leur code pour répondre aux spécifications fonctionnelles.

Le SDLC sécurisé porte sur la conception et le développement de l’application ; DevSecOps vise à transférer la responsabilité de l’environnement de production de chaque application des équipes informatiques traditionnelles aux développeurs. Ceux-ci peuvent ainsi automatiser autant que possible les processus de compilation, de test et de mise en production.

DevOps et DevSecOps ont amorcé une révolution dans la redéfinition du rôle des développeurs logiciels. D’autres changements majeurs, comme les migrations vers le cloud, y ont bien sûr contribué. Mais si donner plus de moyens aux développeurs et accélérer les tests de sécurité est essentiel à la réussite de la plupart des organisations modernes, il serait erroné de réduire la sécurité des applications à un simple défi d’automatisation. Il est plutôt important d’impulser des changements culturels et organisationnels qui sensibilisent à la sécurité et intègrent ces considérations dès les premières étapes du développement. Cette démarche doit s’étendre à toutes les étapes du cycle de vie du développement logiciel, qu’on l’appelle SSDLC ou DevSecOps.

Vers un avenir plus sûr

Les pratiques traditionnelles de test des vulnérabilités en production ne suffisent plus à sécuriser vos applications. À mesure que le secteur du logiciel a évolué, les types d’attaques ont eux aussi changé. Déployer et maintenir une application sécurisée exige de protéger chaque étape de son développement. Cela signifie qu’il faut se poser des questions sur les pratiques de sécurité dès la définition des exigences, adapter la culture et les pratiques de l’équipe pour intégrer une approche axée sur la sécurité, mettre en place des vérifications automatisées dans le processus de déploiement, et adopter de nombreuses autres pratiques qui, ensemble, contribuent à un processus SDLC sécurisé.

Le SSDLC permet de décaler les risques de sécurité vers la gauche et de traiter les problèmes à leur origine, dès la phase de définition des exigences, plutôt que de devoir revenir en arrière depuis la phase de maintenance. En suivant les bonnes pratiques de mise en œuvre du SDLC (même lorsque vous utilisez l’IA !) et en accordant une attention particulière à la sécurité à chaque étape du développement, vous pouvez avoir l’assurance que votre application sera bien mieux sécurisée.