Cycle de développement logiciel sécurisé (SDLC sécurisé)

La sécurité est cruciale pour toute application qui englobe des fonctionnalités critiques. Il peut s’agir d’une opération simple, comme la sécurisation de votre base de données contre des actes malveillants, ou complexe, comme l’application d’un traitement anti-fraude à un prospect qualifié avant de l’intégrer dans votre plateforme.

La sécurité s’applique à chaque phase du cycle de vie du développement logiciel (SDLC) et doit être la préoccupation principale de vos développeurs lorsqu’ils implémentent les exigences de votre logiciel. Dans cet article, nous allons explorer les moyens de créer un SDLC sécurisé, qui vous aidera à détecter les problèmes dans les exigences avant qu’ils ne menacent la sécurité en production.

Il est possible de traiter les problèmes de sécurité dans le pipeline SDLC, bien avant le déploiement en production. Cela réduit le risque de vulnérabilités de l’application et permet d’en minimiser l’impact lorsqu’elles sont découvertes.

L’objectif du SDLC sécurisé n’est pas d’éliminer complètement les contrôles de sécurité traditionnels, tels que les tests de pénétration, mais plutôt d’inclure la sécurité dans les responsabilités des développeurs et de leur donner les moyens de créer des applications sécurisées dès le départ.

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

Le SDLC sécurisé constitue un enjeu majeur car la sécurité des applications est essentielle. L’époque où l’on publiait d’abord et où l’on corrigeait ensuite est révolue. Les développeurs doivent désormais connaître les problèmes de sécurité potentiels à chaque étape du processus. Pour cela, la sécurité doit désormais impérativement être intégrée dans votre SDLC. Comme n’importe qui peut potentiellement accéder à votre code source, vous devez vous assurer de coder en veillant aux vulnérabilités potentielles. Il est donc essentiel de disposer d’un processus SDLC robuste et sécurisé pour éviter que votre application ne fasse l’objet d’attaques de la part de pirates ou d’autres utilisateurs malveillants.

Bref historique des pratiques SDLC

Le cycle de vie du développement logiciel décrit la façon dont sont créées les applications logicielles. Il comprend généralement les phases suivantes :

• Collecte desexigences

• Analyse des exigences pour guider la conception

• Conception de nouvelles fonctionnalités sur la base des exigences

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

• Test et vérification des nouvelles fonctionnalités : confirmation qu’elles répondent effectivement aux exigences

• Déploiement du nouveau projet

• Maintenance et évolution de ces fonctionnalités après publication de la release

Les 7 phases du SDLC

Le modèle en cascade, une des méthodologies les plus anciennes et les plus connues, a jeté les bases de ces phases du SDLC. Développées en 1970, ces phases demeurent en grande partie identiques aujourd’hui. En revanche, les pratiques d’ingénierie logicielle ont connu des bouleversements qui ont redéfini la façon de concevoir les logiciels.

Traditionnellement, les logiciels étaient écrits pour des applications très spécialisées, et le développement des programmes selon la méthodologie en cascade n’aboutissait souvent qu’après des années. Les pratiques modernes visent désormais à accélérer le rythme de l’innovation tout en continuant à créer des applications logicielles performantes. Les entreprises ont abandonné la méthode en cascade et la plupart utilisent une forme ou une autre du SDLC Agile, publié pour la première fois en 2001.

Le développement agile préconise de diviser les grandes releases monolithiques en plusieurs mini-releases (chacune étant réalisée en sprints de deux ou trois semaines), et utilise l’automatisation pour créer et vérifier les applications. Cela permet aux entreprises d’itérer beaucoup plus rapidement. Abandonnant les déploiements monolithiques peu fréquents qui caractérisent les applications régies par le modèle en cascade, le développement agile se concentre souvent sur le déploiement de nouvelles fonctionnalités plusieurs fois par jour, en construisant le logiciel de manière incrémentielle et non d’un bloc.

SDLC et sécurité des applications

Qu’en est-il de la sécurité de ces applications ? En 1970, la plupart des attaques nécessitaient un accès physique à un terminal sur la machine exécutant l’application. Le monde était beaucoup moins interconnecté, ce qui réduisait le risque que des acteurs externes aient un impact sur la sécurité des applications. Alors que de nouvelles méthodologies de développement logiciel étaient mises en pratique au fil des ans, la sécurité était rarement mise en avant au sein du SDLC.

La sécurité des applications est devenue la responsabilité des équipes de sécurité informatique dédiées au support. Au début, les applications étaient testées uniquement après leur lancement. Ces tests étaient effectués dans des environnements de production, souvent seulement une fois par an. Cela signifiait que les vulnérabilités potentielles étaient « dans la nature » et que les attaquants pouvaient les exploiter pendant des semaines, voire des mois, avant qu’elles ne soient détectées et corrigées. C’est pourquoi la plupart des entreprises ont choisi de compléter les tests de production par des tests de sécurité préalables à la publication. Ces tests supplémentaires interviennent en amont, et les applications doivent passer le contrôle de sécurité avant le déploiement du code en production.

Cette étape nécessite souvent plusieurs semaines, ce qui allonge le cycle de release. Pire encore, il est totalement impossible d’en prévoir le résultat : Un test de sécurité peut ne trouver que quelques vulnérabilités qui seront corrigées en quelques jours, ou en trouver des dizaines, voire des centaines. Leur correction nécessite parfois des modifications majeures du code qui remplacent des composants sous-jacents entiers, le tout devant ensuite être revérifié en fonction des exigences de l’application et d’un autre test de sécurité.

Résultat : il est fréquent que les développeurs prennent plusieurs semaines de retard, sans renoncer pourtant à tenir des délais devenus irréalistes. Cela cause de nombreuses frictions au sein des structures, et les entreprises se retrouvent face à un dilemme : accepter le risque et publier une application présentant des vulnérabilités ou ne pas respecter les délais (ou les deux). Pire encore, la résolution d’un problème découvert aussi tard dans le cycle de développement logiciel peut coûter jusqu’à 100 fois plus cher que sa résolution au début du processus (nous y reviendrons).

L’accélération de l’innovation et de la fréquence des releases n’a fait qu’aggraver tous ces problèmes. Il a fallu repenser le rôle de la sécurité des applications dans le processus de développement logiciel et réfléchir à la création d’un SDLC sécurisé.

Quels sont les processus de SDLC sécurisé ?

La mise en œuvre de la sécurité du SDLC concerne chaque phase du processus de développement logiciel. Elle nécessite d’avoir un état d’esprit axé sur la sécurité de la livraison, et de s’attaquer aux problèmes lors des phases de définition des exigences et de développement, au fur et à mesure de leur découverte. Cette méthode est beaucoup plus efficace et beaucoup moins coûteuse que d’attendre de voir ces problèmes de sécurité apparaître dans l’application déployée. Les processus de cycle de vie de développement logiciel sécurisé intègrent la sécurité en tant que composant de chaque phase du SDLC.

Si l’intégration de la sécurité dans chaque phase du SDLC doit être la priorité de chacun, les questions de sécurité et les tâches associées varient en fait considérablement selon la phase du SDLC.

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

Chaque phase du SDLC doit contribuer à la sécurité de l’application globale. Cela se fait de différentes manières pour chaque phase, avec une remarque essentielle : La sécurité du cycle de vie du développement logiciel doit constituer la principale préoccupation de l’ensemble de l’équipe. Examinons un exemple de cycle de vie de développement logiciel sécurisé pour une équipe créant un portail de renouvellement d’adhésion :

Phase 1 : exigences

Dans cette première phase, les exigences relatives aux nouvelles fonctionnalités sont recueillies auprès des différentes parties prenantes. Il est important d’identifier toutes les considérations de sécurité pour les exigences fonctionnelles recueillies pour la nouvelle release.

• Exemple d’exigence fonctionnelle : l’utilisateur doit pouvoir vérifier ses coordonnées avant de renouveler son adhésion.

• Exemple de considération de sécurité : l’utilisateur ne doit avoir accès qu’à ses propres coordonnées et celles de personne d’autre.

Phase 2 : conception

Cette phase traduit les exigences de façon concrète dans l’application réelle. Ici, les exigences fonctionnelles décrivent généralement ce qui doit se produire, tandis que les exigences de sécurité se concentrent sur ce qui ne doit pas se produire.

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

• Exemple de problème de sécurité : nous devons vérifier que l’utilisateur dispose d’un jeton de session valide avant de récupérer les informations de la base de données. En l’absence de ce jeton, l’utilisateur doit être redirigé vers la page de connexion.

Phase 3 : développement

Lorsque le moment est venu de mettre en œuvre la conception, les préoccupations changent : il s’agit désormais de s’assurer que le code présente toutes les garanties de sécurité. Il existe généralement des directives de codage sécurisé, ainsi que des révisions qui permettent de vérifier que ces directives ont bien été suivies. Ces révisions du code peuvent se faire manuellement ou être automatisées à l’aide de technologies telles que les tests de sécurité des applications statiques (SAST).

Cela dit, les développeurs d’applications modernes ne peuvent pas se préoccuper uniquement du code qu’ils écrivent, car la grande majorité des applications modernes ne sont pas écrites à partir de zéro. Ils doivent s’appuyer sur des fonctionnalités existantes, généralement fournies par des composants open source gratuits, pour proposer de nouvelles fonctionnalités et donc de la valeur ajoutée à l’organisation, aussi rapidement que possible. En fait, plus de 90 % des applications modernes déployées sont constituées de ces composants open source, généralement vérifiés à l’aide d’outils d’analyse de la composition des logiciels (SCA).

Les directives de codage sécurisé, dans ce cas, peuvent inclure :

• L’utilisation de requêtes SQL paramétrées et en lecture seule pour lire les données de la base de données et minimiser les risques que quelqu’un puisse un jour réquisitionner ces requêtes à des fins malveillantes

• La validation des entrées de l’utilisateur avant de traiter les données qu’elles contiennent

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

• La vérification des vulnérabilités des bibliothèques open source avant leur utilisation

Phase 4 : vérification

La phase de vérification est celle où les applications passent par un cycle de test complet pour s’assurer qu’elles répondent à la conception et aux exigences initiales. Ce moment est idéal pour introduire des tests de sécurité automatisés utilisant diverses technologies. L’application n’est pas déployée si ces tests ne sont pas réussis. Cette phase comprend souvent des outils automatisés tels que les pipelines CI/CD pour contrôler la vérification et le déploiement.

La vérification à cette phase peut inclure :

• Des tests automatisés qui expriment les chemins critiques de votre application

• L’exécution automatisée de tests unitaires de l’application qui vérifient l’exactitude de l’application sous-jacente

• Des outils de déploiement automatisés qui échangent dynamiquement les secrets de l’application pour les utiliser dans un environnement de production

Phase 5: Maintenance et évolution

Tout ne s’arrête pas à la publication de l’application. Des vulnérabilités qui sont passées à travers les mailles du filet peuvent être découvertes dans l’application bien après sa publication. Elles peuvent résider dans le code écrit par les développeurs ; toutefois, on les trouve de plus en plus dans les composants open source sous-jacents de l’application. Il en résulte une augmentation du nombre de vulnérabilités « zero-day », c’est-à-dire inconnues jusqu’alors et découvertes en production par les gestionnaires de l’application.

Ces vulnérabilités doivent ensuite être corrigées par l’équipe de développement, un processus qui peut, dans certains cas, nécessiter une réécriture extensive des fonctionnalités de l’application. À ce stade, les vulnérabilités peuvent également provenir d’autres sources, comme des tests de pénétration externes menés par des hackers éthiques ou des soumissions du public dans le cadre de programmes de « bug bounty ». La résolution de ces types de problèmes de production doit être planifiée et prise en compte dans les futures releases.

Les avantages du SDLC sécurisé

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

Les équipes de développement peuvent ainsi planifier correctement les releases, ce qui facilite la détection et la résolution des problèmes susceptibles d’affecter le calendrier de publication. Il est préférable de procéder ainsi que d’avoir une mauvaise surprise lors du déploiement de l’application en production. Le SDLC sécurisé permet donc de maintenir les releases sur la bonne voie.

Par ailleurs, dans le SDLC sécurisé, les efforts de sécurité sont en principe menés par l’équipe de développement elle-même. Les problèmes sont résolus par les experts du domaine qui ont écrit le logiciel plutôt que par une autre équipe qui ne fait que corriger les bogues après coup. Cela permet aux développeurs de s’approprier la qualité globale de leurs applications, et de déployer des applications plus sûres en production.

Les efforts supplémentaires liés aux tests de sécurité dans le cadre du SDLC peuvent sembler fastidieux et coûteux, mais aujourd’hui, la plupart de ces tests sont automatisés, notamment pour les opérations de développement ou DevOps (nous y reviendrons). L’environnement SDLC sécurisé exige une collaboration fréquente entre le DevOps et les ingénieurs qui mettent en œuvre la fonctionnalité de l’application ; cette collaboration doit être intégrée au SDLC.

En réglant ces problèmes au début du processus, les équipes de développement peuvent réduire le coût total de leurs applications. Alors que la découverte de problèmes à un stade avancé du SDLC peut multiplier par 100 le coût de développement nécessaire à leur résolution, comme le montre le graphique ci-dessous.

IBM System Science Institute: Relative Cost of Fixing Defects, 2010

Comme le montre la figure 2 ci-dessus, le passage à un SDLC sécurisé permet aux équipes de développement de créer plus rapidement des applications sécurisées. Il s’agit donc d’un investissement judicieux.

Comment garantir un SDLC sécurisé ?

Pour garantir un SDLC sécurisé, il faut se concentrer à la fois sur le fonctionnement de l’application et sur la manière dont les développeurs transforment les exigences en code applicatif. La sécurité doit être la préoccupation n°1 de l’équipe pendant le développement de l’application. Un changement culturel au sein de vos équipes ainsi que des processus et des contrôles automatisés à chaque étape du développement du logiciel seront peut-être nécessaires.

Garantir la sécurité d’une application dépend fortement des forces et des faiblesses de l’équipe de développement logiciel qui travaille sur la sécurité du cycle de développement logiciel.

Étant donné que le SDLC sécurisé implique la modification des processus existants, la mise en œuvre de nouveaux outils et, plus important encore, un changement culturel au sein d’un certain nombre d’équipes, chaque organisation, voire chaque entité au sein de cette dernière, aura son propre parcours vers un SDLC sécurisé performant.

5 meilleures pratiques pour un SDLC sécurisé

1. Formez vos développeurs

Le SDLC sécurisé s’accompagne de multiples initiatives connexes, notamment :

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

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

• La définition d’attentes claires concernant la rapidité avec laquelle les problèmes découverts en production doivent être traités (ce sont les SLA de remédiation)

Il n’est pas nécessaire que tous ces éléments soient réunis pour mettre en œuvre un SDLC sécurisé efficace, mais comme pour un puzzle, vous devrez assembler suffisamment de pièces pour avoir une vue d’ensemble.

2. Définissez clairement les exigences

Quelle que soit l’application que vous créez, elle doit être facile à comprendre. Les équipes de développement ont besoin d’exigences claires sur lesquelles travailler. Cela s’applique à tous les conseils, recommandations et directives en matière de sécurité. Les vulnérabilités découvertes lors des tests doivent pouvoir être corrigées facilement. Il est essentiel que toutes les personnes, tous les processus et tous les outils impliqués apportent des solutions au lieu d’uniquement signaler les problèmes.

3. Pensez « évolution »

Étant donné que le SDLC sécurisé va bouleverser la façon de travailler et d’interagir de plusieurs équipes, il est important que chacun aborde cette expérience avec l’esprit ouvert, et que l’équipe de sécurité donne aux développeurs les moyens de sécuriser leurs propres applications.

4. Liez l’implémentation à d’autres initiatives

Pour les applications et les équipes bien établies, il est souvent plus facile de mettre en œuvre les changements du SDLC sécurisé lorsqu’ils sont liés à un autre effort de modernisation, comme une transformation du cloud, une initiative DevOps, ou sa variante plus soucieuse de la sécurité, le DevSecOps.

5. Attaquez-vous d’abord aux problèmes majeurs

Concentrez-vous sur les problèmes essentiels et sur les solutions exploitables plutôt que de vous attaquer à chaque vulnérabilité découverte. S’il est parfois possible, pour les applications récentes ou de petite taille, de corriger tous les problèmes de sécurité existants, il n’en est pas toujours de même pour les applications plus anciennes et plus importantes. Un tri peut s’avérer utile. Il s’agit non seulement d’empêcher les problèmes de sécurité d’arriver en production, mais aussi de s’assurer que les vulnérabilités existantes sont triées et corrigées au fil du temps.

Pour plus de conseils sur la sécurisation de votre SDLC, consultez notre liste complète des meilleures pratiques SDLC.

SDLC sécurisé et DevSecOps

Il est important d’aborder la relation entre SDLC sécurisé et DevSecOps. Les deux termes sont parfois utilisés de manière interchangeable, ce qui prête à confusion. Le SDLC sécurisé et le DevSecOps sont étroitement liés. Il s’agit, en fait, de pratiques complémentaires qui partagent le même objectif : permettre aux développeurs de s’approprier davantage leur application, en veillant à ce qu’ils ne se contentent pas d’écrire et tester leur code pour répondre aux spécifications fonctionnelles.

Le SDLC sécurisé se concentre sur la façon dont l’application est conçue et construite ; le DevSecOps cherche à transférer la propriété de l’environnement de production de chaque application des équipes informatiques traditionnelles vers les développeurs. Les développeurs peuvent ainsi se concentrer sur l’automatisation des processus de création, de test et de mise en production.

Le DevOps et le DevSecOps ont amorcé une révolution en redéfinissant le rôle des développeurs de logiciels. Celle-ci a bien sûr été favorisée par d’autres changements majeurs, tels que les transformations du cloud. Mais si le renforcement de l’autonomie des développeurs et l’accélération des tests de sécurité sont les clés du succès pour la plupart des organisations modernes, ce serait une erreur de considérer la sécurité des applications comme une simple question d’automatisation. Au contraire, il est important de conduire des changements de culture et de processus qui contribuent à sensibiliser à la sécurité et à la prendre en compte dès le début du développement. Cela doit imprégner toutes les parties du cycle de vie du développement logiciel, que l’on parle de SDLC sécurisé ou de DevSecOps.

Vers un avenir plus sûr

Les pratiques traditionnelles consistant à tester les vulnérabilités en production ne suffisent plus pour sécuriser vos applications. L’industrie du logiciel a évolué, tout comme les types d’attaques. Pour déployer et maintenir une application sécurisée, il faut sécuriser chaque étape de son développement. Cela signifie qu’il faut poser des questions sur les comportements de sécurité dès la phase de collecte des exigences, adapter la culture et les pratiques de l’équipe pour donner la priorité à la sécurité, mettre en œuvre une vérification automatisée dans votre processus de déploiement, et bien d’autres pratiques qui, ensemble, créent un processus SDLC sécurisé.

Le SDLC sécurisé vous permet d’anticiper davantage les risques de sécurité, en traitant l’origine des problèmes de sécurité dès la phase de recueil des exigences au lieu de devoir revenir en arrière depuis la phase de maintenance. En mettant l’accent sur la sécurité à chaque étape du développement, vous pouvez être certain que votre application sera beaucoup plus sûre.