Points clés
- Le coût de correction d'une vulnérabilité augmente exponentiellement avec l'avancement du cycle de développement — de 1x en phase de conception à 100x en production.
- La modélisation des menaces (threat modeling) est l'outil de conception sécurisée le plus ROI-efficace — elle identifie les risques architecturaux avant que le code ne soit écrit.
- Les exigences de sécurité doivent être formalisées au même titre que les exigences fonctionnelles dès la phase de spécification.
- Le "secure by design" dépasse le périmètre technique — il inclut les décisions d'architecture de données, de gestion des identités et de gestion des erreurs.
La règle du 1-10-100 en sécurité applicative
La règle empirique bien établie en génie logiciel stipule que le coût de correction d'un défaut augmente par facteur 10 à chaque phase du cycle de développement. Un défaut de conception coûte 1 à corriger en phase de conception, 10 en phase de développement, 100 en phase de test, et potentiellement 1000 en production (coûts de patch, tests de régression, déploiement d'urgence, impacts opérationnels). Cette règle s'applique de manière encore plus marquée aux défauts de sécurité, dont la correction en production implique souvent des refactorisations architecturales significatives.
L'argument économique pour investir dans la sécurité dès la conception est donc sans ambiguïté. Pourtant, la pression des délais de mise sur le marché conduit régulièrement à reporter la sécurité en fin de cycle, où son coût est maximal et son impact sur les délais perçu comme bloquant. Cette contradiction doit être gérée par la direction avec une vision budgétaire qui intègre le coût différé des décisions de court terme.
La modélisation des menaces comme outil de conception
La modélisation des menaces (threat modeling) est une technique d'analyse structurée qui identifie les menaces, vulnérabilités et risques dans une architecture à un stade où les corrections sont peu coûteuses. Les méthodes les plus répandues — STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), PASTA (Process for Attack Simulation and Threat Analysis), ou les arbres d'attaque — permettent de décomposer l'architecture en composants, d'identifier les flux de données sensibles, et de raisonner sur les menaces que chaque composant et chaque flux peut subir.
Un threat modeling efficace implique des équipes mixtes : architectes, développeurs, représentants des équipes sécurité, et idéalement des représentants métier qui apportent la perspective du modèle de menace réel (qui veut attaquer ce système et pourquoi ?). Il doit être réalisé à chaque changement architectural significatif, pas seulement lors de la conception initiale.
Formaliser les exigences de sécurité
Les exigences de sécurité doivent être documentées dans les spécifications fonctionnelles au même titre que les exigences de performance ou d'accessibilité. Cette documentation prend généralement la forme d'un Security Requirements Document ou d'user stories de sécurité qui décrivent les comportements attendus du système d'un point de vue sécurité : "Le système ne doit pas exposer les messages d'erreur détaillés à l'utilisateur final", "Toutes les communications entre le client et le serveur doivent utiliser TLS 1.2 minimum", "Les tokens d'authentification doivent avoir une durée de vie maximale de 30 minutes avec possibilité de révocation immédiate".
Ces exigences deviennent des critères d'acceptation vérifiables lors des phases de test et des revues de code. Sans formalisation préalable, les critères de validation de la sécurité restent subjectifs et dépendants de l'expertise individuelle des reviewers.
Les dimensions non-techniques du secure by design
Le secure by design dépasse la sécurité du code. Il inclut la conception de l'architecture de données (quelles données sont collectées, pourquoi, où elles sont stockées, quelle est leur durée de rétention — en conformité avec les principes de minimisation des données), la conception de la gestion des identités (modèle d'authentification, structure des rôles et permissions, mécanisme de révocation), la conception de la gestion des erreurs (ce qui est journalisé, ce qui est retourné à l'utilisateur, comment les erreurs sont alertées), et la conception de la chaîne de dépendances (comment les dépendances tierces sont évaluées, approuvées et mises à jour).
Ces dimensions architecturales ont des implications de sécurité aussi importantes que le code lui-même — elles conditionnent la surface d'exposition du système et la qualité des informations disponibles pour la détection et la réponse aux incidents.