Qu’est-ce que le SDLC sécurisé (Secure Software Development Lifecycle) ?

La sécurité logicielle en exemples

Avant de découvrir comment intégrer la sécurité au SDLC, il est important de bien cerner les différents types d’activités qu’elle regroupe. Voici quelques exemples de pratiques déjà mises en place (ou en cours de déploiement) dans de nombreuses entreprises pour renforcer la sécurité logicielle.

Analyse statique

L’analyse statique permet de scanner le code source à la recherche de défauts et de vulnérabilités. Ce processus (souvent automatisé) identifie les schémas connus symptomatiques d’un code mal sécurisé dans un projet logiciel, par exemple dans une Infrastructure-as-Code (IaC) ou dans le code applicatif. Les développeurs peuvent ainsi corriger les problèmes bien avant que le logiciel ne parvienne jusqu’à l’utilisateur final.

Scans de sécurité

Comme l’analyse statique, le scan de sécurité est un processus généralement automatique utilisé pour détecter les vulnérabilités et les erreurs de configuration dans toute l’application, y compris dans son infrastructure sous-jacente. Ces scans incluent par exemple des analyses de script intersites, un scan des ports ou encore une analyse des vulnérabilités de container.

Revues de code

Les scans automatisés sont certes très efficaces, mais il est toujours utile de faire inspecter le code par un humain avant de le déployer en production. La plupart des développeurs effectuent déjà des revues de code pour détecter les défauts et les erreurs logiques passés entre les mailles de filet. Mais avec la bonne stratégie, cette pratique peut également leur permettre de repérer des vulnérabilités moins communes pour éviter qu’elles ne contaminent le codebase.

Tests d’intrusion

Cette pratique beaucoup plus intensive fait intervenir des experts en cybersécurité, embauchés par l’entreprise pour tester la sécurité de son infrastructure de production. Les pentesters ont recours pour ce faire à différentes méthodes, de la simple analyse de vulnérabilités à l’exécution d’exploit. À l’issue de la mission, ils établissent un rapport listant les problèmes qui ont échappé aux contrôles de sécurité.

Bug Bounty

Ce dispositif assez récent est similaire aux tests d’intrusion, avec néanmoins quelques différences. Ces programmes encouragent les utilisateurs à signaler des vulnérabilités qu’ils ont eux-mêmes détectées, en échange d’une récompense financière. Ils sont ainsi moins enclins à exploiter ces vulnérabilités pour leur propre intérêt.

Formation

Il ne faut jamais sous-estimer le pouvoir d’une bonne formation. La cybersécurité ne cesse d’évoluer et bon nombre de conseils et de connaissances que nous prenions pour acquises il y a dix ans ne sont plus d’actualité. De la même manière, ce que nous savons aujourd’hui n’aura peut-être plus cours dans une décennie. Les formations de sécurité sont donc extrêmement importantes pour identifier et corriger les nombreuses vulnérabilités dues aux erreurs humaines.

Sécuriser le cycle de développement logiciel

Des mécanismes de protection greffés à la va-vite ne suffiront pas. La sécurité doit s’intégrer à la trame même du cycle de développement. Il n’y a donc pas de « phase de sécurité » à proprement parler, mais plutôt une série de bonnes pratiques et d’outils que vous pouvez (et devez) inclure à toutes les étapes de votre SDLC : implication des équipes de sécurité, déploiement d’outils automatisés, formations, etc. Considérez la sécurité non pas comme une simple case à cocher, mais plutôt comme une évolution de votre processus. Vous pourrez ainsi inscrire ces nouvelles pratiques dans le temps et en tirer plus de valeur.

1. Cahier des charges

   La première phase du SDLC consiste à cerner le problème et les objectifs pour établir un cahier des charges de sécurité. À ce stade, les tickets (signalements de bugs, demandes de fonctionnalités, vulnérabilités, etc.) deviennent des projets. Dans un SDLC sécurisé, le plus gros challenge est d’identifier les priorités. Impliquer l’équipe de sécurité dans le processus vous donnera plus de contexte pour évaluer l’impact de chaque nouvelle fonctionnalité ou de chaque nouveau correctif qui entre dans le SDLC.

2. Planification

   Vous avez identifié le problème. Il vous faut maintenant trouver la solution et décider ce que vous allez construire. Comme à l’étape précédente, recueillez le feedback de l’équipe de sécurité pour vous assurer que la solution proposée résout le problème tout en préservant la sécurité du client et la valeur qu’ils retirent de l’application.

3. Conception

   Une fois les exigences de sécurité définies, vous devez déterminer comment créer la solution dans votre application. Il vous faudra généralement concevoir l’architecture de bout en bout. Posez-vous les bonnes questions : quel sera l’impact sur les systèmes ? Quels services seront créés ou modifiés ? Comment les utilisateurs interagiront-ils avec cette fonctionnalité ? Chaque concept doit être étudié et approuvé par l’équipe d’ingénierie, mais aussi par l’équipe de sécurité qui pourra identifier les failles potentielles. Ces trois premières phases nécessitent une communication constante avec toutes les parties prenantes, faute de quoi certains problèmes risquent de passer sous les radars et d’être détectés trop tard dans le processus.

4. Implémentation

   Place au concret. Vos idées doivent être transposées en code. C’est là que certains mécanismes de sécurité mentionnés plus haut interviennent. L’analyse statique est une solution peu coûteuse et facile à mettre en œuvre. Elle peut être utilisée sur chaque commit ou chaque push pour donner aux développeurs un feedback en temps quasi réel sur l’intégrité du code qu’ils sont en train d’écrire.

   Une fois le code terminé et le processus de revue enclenché, une équipe expérimentée prend le relais pour détecter les problèmes de logique et les vulnérabilités. Comme pour la qualité des produits, la protection de l’entreprise est l’affaire de tous, et non pas uniquement de l’équipe de sécurité.

5. Tests et déploiement

   Le code est écrit et revu par les acteurs concernés. Il faut maintenant le tester avant de le déployer en production. Les outils de scan plus robustes entrent alors en action pour une analyse approfondie de la sécurité de l’application. Des tests manuels peuvent également être effectués, en fonction de la taille de la fonctionnalité et des ressources disponibles. À mesure que des vulnérabilités sont identifiées, des solutions peuvent être intégrées aux outils automatisés existants pour éviter toute nouvelle occurrence.

6. Maintenance

   Déployer du code en production ne se résume pas à appuyer sur un bouton puis à oublier son existence. Les ressources changent, des bugs apparaissent, des failles sont détectées… le code doit être suivi et maintenu en permanence pour garantir son intégrité, jour après jour. Si la phase de maintenance sert généralement à identifier et à corriger les défauts dans le code, c’est aussi à ce stade que les vulnérabilités sont découvertes.

   Vous devez néanmoins garder à l’esprit qu’un code sécurisé ne le restera pas toujours. Des risques de la supply chain aux exploits zero-day, le paysage de la sécurité évolue constamment. Un SDLC sécurisé passe donc par un processus capable d’identifier et de résoudre les problèmes au fur et à mesure qu’ils surgissent.

7. Retour à la première étape

   Le SDLC est un processus sans fin qui se répète en permanence. Lorsque vous arrivez au bout, vous devez revenir au point de départ. Chaque bug, amélioration ou vulnérabilité identifiés aux phases de test ou de maintenance lancera un nouveau cycle et la définition d’un nouveau cahier des charges. Bref, le développement sécurisé de logiciel est un cycle d’amélioration continue.

Conclusion : pour aller plus loin

S’il existe une multitude de méthodes pour intégrer la sécurité au SDLC, dont certaines sont déjà en application dans votre entreprise, d’autres mécanismes robustes vous permettront de renforcer davantage la protection de votre cycle de développement. Les ressources ci-dessous sont un bon point de départ pour impulser cette transition.

SAMM de l’OWASP

Le SAMM (Software Assurance Maturity Model) est un modèle de maturité d’assurance logicielle publié par l’OWASP. Successeur du CLASP (Comprehensive, Lightweight Application Security Process), ce framework robuste fournit des recommandations claires pour intégrer les pratiques de sécurité au processus de développement logiciel. Il met notamment l’accent sur la nécessité d’adapter ces mécanismes au profil de risque de l’entreprise.

SSDF du NIST

Le SSDF (Secure Software Development Framework) est une série de pratiques fondamentales conçues pour sécuriser le développement logiciel. Ce framework publié par le NIST s’appuie sur les bonnes pratiques mises au point par plusieurs organismes axés sur la sécurité (notamment l’OWASP). Il décompose le SDLC en quatre étapes clés, chacune pensée pour renforcer la posture de sécurité logicielle de l’entreprise.

• Préparer l’entreprise – Assurez-vous que les collaborateurs, les processus et les technologies sont prêts à suivre un SDLC sécurisé, au niveau organisationnel, mais aussi au niveau individuel, dans chaque équipe de développement et pour chaque projet.
• Protéger le logiciel – Protégez tous les composants du logiciel contre les altérations et les accès non autorisés.
• Concevoir des logiciels sécurisés – Développez des logiciels sécurisés en limitant au maximum le nombre de vulnérabilités à chaque publication.
• Corriger les vulnérabilités – Identifiez les vulnérabilités passées entre les mailles du filet après publication. Mettez en place les mesures appropriées pour les corriger et éviter toute récidive.