La sécurité du développement logiciel

Domaine 8 du CISSP

Le développement logiciel n’est pas seulement une équipe de programmeurs écrivant du code. Car dans notre monde hélas hostile, un bon logiciel doit certes fonctionner, mais aussi résister aux erreurs, aux usages malveillants et aux cyberattaques. C’est tout l’enjeu du domaine 8 du CISSP, dédié à la sécurité du développement logiciel.

Son principe ? Penser sécurité dès le début, plutôt que de l’ajouter à la fin. Cela évite des corrections tardives, souvent coûteuses, et permet de créer des applications plus fiables et plus solides.

Ce domaine couvre ainsi les bonnes pratiques pour concevoir des logiciels sûrs, qu’il s’agisse d’une application bancaire, d’un site de commerce en ligne ou d’un objet connecté.

 

Cycle de vie

Le développement suit plusieurs étapes. Chacune d'elles présente des enjeux de sécurité.

Tout commence par la phase de conception. Les besoins sont analysés, les fonctionnalités définies et les choix techniques effectués. Dès ce moment, il faut réfléchir aux risques : quelles données seront manipulées ? Qui pourra accéder au logiciel ? Quelles conséquences aurait une fuite d'informations ?

Vient ensuite le développement proprement dit. Les développeurs traduisent les besoins en programmes informatiques. Ils doivent appliquer des règles de programmation sécurisée afin d'éviter d'introduire des vulnérabilités dans le logiciel.

Une fois le développement terminé, le logiciel est soumis à une série de tests destinés à vérifier son bon fonctionnement, mais aussi sa résistance face aux attaques. Enfin, l'application est déployée auprès des utilisateurs puis sera régulièrement mise à jour et maintenue.

La sécurité doit donc accompagner chaque étape du cycle de vie du développement logiciel. On parle de Security by Design, c'est-à-dire le fait de concevoir un logiciel sécurisé dès son origine plutôt que d'essayer de le protéger juste avant d’être livré.

 

Concevoir avant de programmer

La phase de conception est souvent sous-estimée. Pourtant, de nombreuses failles trouvent leur origine dans de mauvaises décisions prises très tôt dans un projet. Ainsi, avant même d'écrire une seule ligne de code, les équipes doivent se poser plusieurs questions.

  • Le logiciel stockera-t-il des informations personnelles ?
  • Les utilisateurs devront-ils s'authentifier ?
  • Quelles opérations seront autorisées selon le profil de chaque utilisateur ?
  • Les données devront-elles être chiffrées ?

Soit une application destinée à gérer des dossiers médicaux. Si les développeurs ne prévoient pas dès le départ une limite l'accès aux dossiers selon la fonction des utilisateurs, il sera très difficile d'ajouter cette protection par la suite.

 

Bonnes pratiques de programmation

Une fois la conception terminée commence l'étape de développement. Les développeurs doivent écrire un code capable de résister aux erreurs et aux tentatives d'exploitation. Pour cela, ils suivent des règles de programmation sécurisée.

Par exemple, ils veillent à vérifier systématiquement les informations saisies par les utilisateurs. Une application ne doit jamais supposer que les données reçues sont correctes ou bienveillantes. De plus, ils doivent gérer les erreurs : un message affichant des informations techniques détaillées peut involontairement fournir des renseignements utiles à un attaquant.

Une autre bonne pratique consiste à appliquer le principe du moindre privilège. Une application ne doit disposer que des droits strictement nécessaires à son fonctionnement. Ainsi, si elle est compromise, les conséquences restent limitées.

accès refusé

Enfin, le code est relu par d'autres développeurs. Ce regard extérieur permet de détecter des erreurs ou des oublis.

 

Protection des données

Bon nombre de logiciels manipulent des informations sensibles : données personnelles, informations bancaires, dossiers médicaux... Comment les protéger ?

Certaines données doivent être chiffrées lorsqu'elles sont enregistrées sur un disque ou lorsqu'elles circulent sur un réseau. En outre, il faut en limiter l'accès. Tous les utilisateurs ne doivent pas voir les mêmes informations ni disposer des mêmes autorisations.

 

Tests fonctionnels et de sécurité

L’objectif des tests est de s’assurer que le logiciel répond aux exigences fonctionnelles, mais aussi aux exigences de sécurité. Les équipes doivent vérifier si l'application réagit correctement face à des situations inattendues. Par exemple :

  • un utilisateur saisit des informations incorrectes,
  • un mot de passe erroné est utilisé plusieurs fois,
  • un fichier beaucoup plus volumineux que prévu est envoyé,
  • plusieurs utilisateurs réalisent simultanément la même opération…

En complément des tests fonctionnels, des tests spécifiques consistent à rechercher les vulnérabilités susceptibles d'être exploitées par un attaquant.

Certains outils analysent automatiquement le logiciel afin de détecter des erreurs fréquentes dans le code. D'autres tests sont réalisés directement sur l'application en fonctionnement pour vérifier sa résistance face à divers scénarios d'attaque. Enfin, des pentesters peuvent réaliser des tests d'intrusion.

 

Assurance qualité

Le développement sécurisé repose aussi sur les équipes d'assurance qualité, souvent appelées QA (Quality Assurance). Leur mission consiste à vérifier que le logiciel répond aux exigences définies au début du projet. Notamment :

  • le bon fonctionnement des différentes fonctionnalités,
  • les performances de l'application,
  • le respect des règles de sécurité…

Les spécialistes de l'assurance qualité collaborent avec les développeurs afin de signaler les anomalies découvertes lors des tests. L'objectif n'est pas de trouver des responsables, mais d'améliorer progressivement la qualité du logiciel.

 

Exemple concret

Soit une entreprise qui développe un dispositif médical connecté destiné à enregistrer les constantes de patients hospitalisés, donc des informations sensibles à protéger.

Avant la commercialisation, plusieurs vérifications sont réalisées.

  • Les équipes s'assurent que le chiffrement des données est correctement configuré afin qu'un tiers ne puisse pas lire les informations stockées dans l'appareil.

  • Elles vérifient que seuls les professionnels de santé autorisés peuvent consulter les données des patients.

  • Enfin, des tests permettront de confirmer que le dispositif continue à fonctionner correctement même s'il reçoit des données inhabituelles ou s'il subit des tentatives d'accès non autorisées.

 

Maintenance

Une application évolue et de nouvelles fonctionnalités sont ajoutées, des erreurs sont corrigées et des vulnérabilités sont découvertes au fil du temps. Les éditeurs publient donc des mises à jour pour améliorer la sécurité de leurs produits. Ces correctifs permettent de supprimer des failles connues avant qu'elles ne soient exploitées par des personnes malveillantes.

Un logiciel qui n'est plus mis à jour finit par présenter un niveau de risque de plus en plus élevé.

 

Responsabilité collective

Le domaine 8 du CISSP rappelle que la sécurité ne dépend pas que d'une seule personne. Les responsables métier définissent les besoins de sécurité. Les architectes conçoivent le logiciel. Les développeurs écrivent un code robuste. Les spécialistes de l'assurance qualité réalisent les vérifications nécessaires. Les experts en cybersécurité effectuent des tests spécifiques et accompagnent les équipes dans l'amélioration continue du produit. Cette collaboration est essentielle, car une seule erreur peut parfois compromettre l'ensemble d'une application.

Le développement sécurisé repose donc autant sur les compétences techniques que sur l'organisation du travail et la communication entre les différents acteurs du projet.

 

boule de cristal piratée