Vous avez pour projet de déployer une nouvelle application web ? Parfait, démarrons tout de suite en découvrant le cheminement idéal à suivre !
Étape 1 : Planification
L'étape de planification, souvent appelée étape de faisabilité, est la première marche du cycle de vie du développement logiciel (SDLC). Ici, nous préparons les bases de tout ce qui suivra. C'est un peu comme établir le plan d'une maison avant de commencer la construction : sans cela, nous risquons de construire une structure instable.
Qu’est-ce que mon entreprise doit définir à cette étape ?
Avant de plonger dans les détails techniques ou de commencer à coder, il est essentiel de prendre du recul pour comprendre pleinement ce que vous souhaitez réaliser et comment vous prévoyez de le faire.
L’étape de planification doit définir les parties prenantes dans les différentes étapes du projet :
Les développeurs
Les architectes
Le management, etc.
Identifier les ressources nécessaires (humaines, matérielles et financières) permettra d’avoir un budget maîtrisé pour le développement de votre nouvelle application web.
Lors de cette étape, vous devez vous poser les bonnes questions :
Quels sont les objectifs à court et à long terme de l'application ?
Comment pouvons-nous mesurer le succès du projet ?
En engageant toutes les parties prenantes dans ce processus, vous mettez votre projet sur la voie du succès.
Peux-tu me citer un exemple à suivre sur lequel je peux me baser ?
Pour chaque étape, je vais vous présenter deux scénarios. Un des scénarios est celui d'une équipe qui a compris, qui applique les meilleures pratiques et qui navigue dans le SDLC efficacement – appelons ça le scénario mature. Et l’autre scénario, eh bien, c'est un peu l'opposé. On va voir ensemble des situations où les choses ne se passent pas aussi bien - on appellera ça le scénario peu mature.
L'idée, c'est de vous montrer le bon et le moins bon côté des choses. Comme ça, vous pourrez mieux comprendre comment mettre en œuvre les bonnes pratiques dans vos propres projets et, surtout, comment éviter les faux pas qui pourraient ralentir ou compromettre vos développements.
Scénario peu mature
Dans un scénario peu mature, la sécurité est souvent une réflexion tardive. Les discussions se concentrent principalement sur les fonctionnalités et les performances, sans prendre en compte les implications en matière de sécurité.
Par exemple, une équipe peut décider de négliger les aspects sécurité lors des développements afin d'accélérer la mise en production de l’application ou ne pas faire appel à l’équipe sécurité pour la réalisation du projet.
Scénario mature
Dans un scénario mature, la sécurité est intégrée dès l’étape de planification. L'équipe commence par une évaluation des risques pour identifier et prioriser les menaces potentielles.
Par exemple, si l'application doit gérer des données sensibles, les besoins en matière de cryptographie, de gestion des sessions et de contrôle d'accès sont clairement définis et prévus dans le planning.
Quelle ressource puis-je utiliser à cette étape ?
Cette approche est soutenue par l'utilisation de cadres de référence tels que l'OWASP Application Security Verification Standard (ASVS), notamment dans sa partie V1 qui fournit une liste de contrôles de sécurité à considérer dès le début du projet.
L’utilisation de la catégorie “Governance” du modèle SAMM (ou Software Assurance Maturity Model) peut être également une source de référence.
J’ai terminé la planification du projet de création d’une nouvelle application web, que dois-je faire maintenant ?
Très bien ! Passons maintenant à la seconde étape, la définition de vos besoins !
Étape 2 : Analysez et définissez le besoin
L’étape de définition des besoins est la seconde étape dans votre projet de développement d'une application. C'est à ce moment que sont identifiés et précisés les besoins fonctionnels et non fonctionnels du système, y compris les exigences de sécurité.
Imaginez que vous êtes architecte. Avant de dessiner les plans ou de choisir les matériaux, vous devez comprendre les besoins de ceux qui utiliseront le bâtiment.
Cette étape oriente toutes les décisions futures en matière de conception et de développement. Elle implique une analyse approfondie pour comprendre les objectifs de votre application, le public cible, les données à traiter, et surtout, les risques potentiels et les menaces de sécurité.
Cette étape sert également à élaborer un document spécifique : Spécifications des Exigences Logicielles (Software Requirements Specification - SRS). Le SRS sert de feuille de route détaillée, garantissant que tous les aspects du projet sont clairement définis, compris par toutes les parties prenantes, et méticuleusement alignés avec les objectifs finaux du projet, facilitant ainsi une réalisation sans faille.
D’un point de vue sécurité, quelles questions dois-je me poser ?
C'est le moment de poser des questions fondamentales :
Quelles sont les ressources à protéger ?
Quels types d'attaques devons-nous anticiper ?
Comment pouvons-nous assurer la confidentialité, l'intégrité et la disponibilité des données traitées par l'application ?
Scénario peu mature
Dans un scénario peu mature, l'équipe se précipite pour recueillir les exigences sans véritable plan ou engagement avec les utilisateurs finaux, conduisant à une compréhension superficielle des besoins. Les informations sont collectées de manière désorganisée, souvent par des moyens impersonnels comme des e-mails, et les besoins documentés restent vagues et non validés. Cette approche précipitée et peu rigoureuse mène à des malentendus et à un produit final qui ne répond pas aux attentes des utilisateurs.
Lorsque les exigences sont rassemblées sans attention particulière à la sécurité, on court le risque de créer un produit vulnérable. La grande différence ici est que, contrairement à d'autres aspects, les lacunes en matière de sécurité ne sont pas toujours évidentes pour les utilisateurs finaux, qui ne sont généralement pas experts en la matière, et ne peuvent donc pas lever l’alerte. Ainsi, même si l'application semble fonctionner correctement, une collecte d'exigences négligente peut laisser passer des failles de sécurité critiques, qui restent inaperçues jusqu'à ce qu'elles soient exploitées.
Scénario mature
Dans un scénario mature, l'équipe adopte une démarche méthodique, engageant directement les parties prenantes et les utilisateurs finaux dès le début. Les besoins sont collectés à travers des interactions significatives, comme des ateliers et des réunions individuelles, puis sont soigneusement documentés et validés. Cette approche assure que le produit final est bien aligné avec les attentes et besoins des utilisateurs, réduisant ainsi les risques de redéveloppement et augmentant la satisfaction des utilisateurs.
Quelles ressources puis-je utiliser à cette étape ?
Comme lors de l’étape de planification, cette approche est soutenue par l'utilisation de cadres de référence tels que l'OWASP Application Security Verification Standard (ASVS), notamment dans sa partie V1 qui fournit une liste de contrôles de sécurité à considérer dès le début du projet.
En résumé
La première étape du SDLC, la planification, permet de s'assurer que le projet respecte les délais, le budget et les objectifs fixés, tout en identifiant les ressources nécessaires.
Intégrer la sécurité dès le début du projet est crucial ; l'utilisation de cadres tels que l'OWASP ASVS dès l’étape de planification aide à prévenir les vulnérabilités.
L’étape d'analyse et de définition des besoins est déterminante pour comprendre en profondeur les attentes fonctionnelles et non fonctionnelles, en insistant sur l'importance de poser les bonnes questions de sécurité.
L'élaboration d'un SRS (Spécifications des Exigences Logicielles) est essentielle pour aligner tous les aspects du projet avec les objectifs finaux, assurant une réalisation cohérente et conforme aux attentes des parties prenantes.
Nous sommes désormais prêts à plonger dans les étapes suivantes du SDLC : le Design et l'Implémentation, où nos idées commencent véritablement à prendre forme et à se transformer en solutions concrètes.
