Votre code est désormais prêt et il a passé les analyses statiques et dynamiques, vous êtes prêt à passer à la prochaine étape: Test et intégration.
Étape 5 : Test et intégration
Dans l’étape 4 nous avons déjà fait de l’analyse statique et de l’analyse dynamique, y a-t-il d’autres tests à prévoir ?
L'étape précédente se concentre sur le développement du code et l'intégration des fonctionnalités selon les spécifications définies. Elle met l'accent sur l'écriture du code, l'analyse statique, et les tests unitaires pour garantir que le logiciel répond aux exigences fonctionnelles et de sécurité initialement posées.
Mais alors vous me direz : quelle est la différence entre l’étape 4 et cette étape 5 ?
L'étape 5 "Tests et Intégration" va au-delà de l’étape 4 en appliquant une validation du fonctionnement de l’application et de la sécurité de bout en bout à travers des tests plus approfondis, incluant des tests manuels ou automatiques avancés. Cette étape vise à détecter les vulnérabilités que l'analyse statique et dynamique ne peuvent pas trouver, et à s'assurer que le produit est prêt pour le déploiement dans un environnement de production.
Pour compléter cette approche, des tests d’intrusion sont effectués sur les nouvelles fonctionnalités lors de déploiement, ainsi que sur l'ensemble de l'application de manière régulière, afin d'identifier et de corriger les vulnérabilités avant qu'elles ne puissent être exploitées par des attaquants.
Jusqu’ici, vous étiez en charge de l’ensemble des tests pour votre application web. Mais est-ce bien raisonnable ?
S'auto-évaluer c'est indispensable, mais avoir le regard d'un tiers aussi ! D'une part parce que le tiers va apporter un regard neuf et donc identifier des problèmes potentiellement passés inaperçus. D'autre part pour rassurer vos clients quant à l'indépendance et donc la qualité de l'audit.
Imaginez que vous envisagiez d'acheter une voiture. Le vendeur, sans aucune expertise en mécanique, vous assure avoir réalisé lui-même une inspection complète, prétendant n'avoir détecté aucun défaut. Seriez-vous entièrement rassuré par ses affirmations, sans l'ombre d'un doute ?
Eh bien non, pour vous c’est le contrôle technique effectué par un tiers qui va faire foi sur l’état du véhicule ! Le test d’intrusion réalisé par un tiers va permettre de s’inscrire dans une démarche d’amélioration continue.
Après avoir apporté les modifications nécessaires remontées par le test d’intrusion, vous pouvez déployer votre application en production ! Félicitations !
Tout n’est pas gagné pour autant. Il sera important de mettre en place de la supervision et du monitoring afin de détecter toutes les attaques contre votre application web !
Scénario peu mature
Votre entreprise a déployé l’application en production sans faire de test d’intrusion. Peu de temps après, un de vos principaux clients a conduit un test d’intrusion sur votre application qui a révélé des failles critiques concernant l’accès aux données. Ce dernier a perdu confiance en votre application et ne souhaite plus collaborer avec vous.
Scénario mature
Votre entreprise a mis en place une politique stricte en matière de tests de sécurité avant le déploiement de toute application en production. Avant le lancement de votre nouvelle application web, une série de tests d'intrusion a été planifiée et réalisée par un prestataire labellisé PASSI. Ces tests ont permis d'identifier et de corriger plusieurs vulnérabilités, assurant ainsi un niveau élevé de sécurité.
Quelles ressources puis-je utiliser à cette étape ?
L’outil proposé par OWASP, Zed Attack Proxy, va vous permettre d’automatiser l’étape de test et de scan de vulnérabilité.
Le Web Security Testing Guide peut également vous guider dans des scénarios de tests applicables à votre application.
Lors de l’étape de déploiement en production, vous pouvez vous appuyer sur le Mod Security Core Rule Set afin de détecter et bloquer les attaques contre votre application web !
Étape 6 : Maintenance
Votre application est désormais en production et utilisée au quotidien par les utilisateurs finaux.
Cette transition marque le début d'une nouvelle étape : la maintenance.
À ce stade, l'attention de l'équipe se porte sur deux axes principaux : la correction des bugs signalés par les utilisateurs et l'amélioration continue de l'application.
Les retours des utilisateurs sont une mine d'informations précieuse, révélant des bugs qui n'avaient pas été détectés lors des étapes de test. La réactivité dans la correction de ces bugs est cruciale pour maintenir la confiance des utilisateurs et assurer la stabilité de l'application. L'équipe se consacre donc à identifier, prioriser et résoudre ces problèmes au fur et à mesure de leur remontée.
L'amélioration continue joue un rôle central dans cette étape. Elle se traduit par l'ajout régulier de nouvelles fonctionnalités répondant aux besoins émergents des utilisateurs et l'optimisation de l'application pour renforcer sa performance et sa sécurité. Cette démarche d'évolution continue permet de garder l'application pertinente et compétitive sur le marché.
Corrigez les vulnérabilités zero day
Vous ne pouvez jamais être entièrement sûr que votre application web ne sera pas attaquée via l’exploitation d’une vulnérabilité qui n’a pas de correctif. C’est ce qu’on appelle les vulnérabilités zero-day. Lorsque des vulnérabilités zero day sont découvertes, les éditeurs de logiciels développent un correctif pour corriger la vulnérabilité.
La découverte d'une telle faille impose une action immédiate : l'équipe doit évaluer le risque, développer un correctif ou utiliser celui proposé par l’éditeur et le déployer dans les plus brefs délais pour protéger l'application et ses utilisateurs contre d'éventuelles exploitations.
En somme, l’étape de maintenance est un engagement continu envers la qualité et la sécurité de l'application, nécessitant une vigilance constante et une capacité à répondre rapidement aux imprévus.
Scénario peu mature
Peu après le déploiement de votre application, les utilisateurs commencent à signaler des bugs critiques impactant l'expérience utilisateur. L'équipe de développement, déjà surchargée par le développement de nouvelles fonctionnalités, met plusieurs semaines à répondre à ces retours. De plus, lorsqu'une vulnérabilité zero-day est révélée, l'équipe n'a ni le processus ni les outils pour y répondre rapidement.
Pendant ce temps, la situation côté sécurité devient encore plus critique. Alors que les vulnérabilités critiques commencent à peine à être identifiées, l'équipe observe une augmentation alarmante du nombre d'attaques réussies exploitant ces failles, se retrouvant impuissante face à l'urgence de la situation. Sans les processus ou les outils adéquats pour une intervention rapide, cette vulnérabilité zero-day force l'équipe à prendre une décision drastique : fermer temporairement le site pour éviter d'autres dommages.
Scénario mature
Dès le lancement de l'application, l'équipe instaure un processus de suivi des bugs, traitant les retours utilisateurs avec une grande réactivité. Un système de priorisation des bugs est en place, permettant de corriger rapidement les problèmes les plus critiques. Lorsqu'une vulnérabilité zero-day est détectée, l'équipe met en œuvre un processus bien rodé pour évaluer le risque et déployer un correctif de manière rapide, minimisant ainsi l'exposition au risque.
Quelles ressources puis-je utiliser à cette étape ?
L’organisation OWASP dispose d’une API appelée The OWASP Enterprise Security API (ESAPI). Elle peut être utilisée pour sécuriser vos applications web.
En résumé
Après corrections des vulnérabilités identifiées lors des tests d'intrusion, l'application peut être déployée en toute sécurité.
Le test d’intrusion réalisé par un tiers permet d’obtenir une perspective neuve et indépendante.
Il est important de mettre en place une surveillance continue pour détecter et réagir rapidement aux attaques potentielles contre votre application.
Lorsqu’une vulnérabilité zero-day est publiée, un patch doit être rapidement mis en place
Nous avons désormais exploré les différentes étapes du cycle de vie. Félicitations ! Voyons ensemble plus en détail dans le prochain chapitre l’ensemble des ressources produites par l’OWASP pour vous aider tout au long du SDLC.
