Deux approches s'opposent en matière de sécurité : l'intégrer dès la conception ou l'ajouter après coup. La première demande un effort initial plus important mais produit des systèmes naturellement robustes. La seconde semble plus rapide mais génère une dette de sécurité qui finit toujours par se payer, souvent au pire moment. Cette page compare les deux approches avec des exemples concrets, s'appuie sur les principes CISA Secure-by-Design et sur le OWASP Top 10:2025, et donne une méthode pour faire basculer une équipe vers la sécurité intégrée.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Distinguer la sécurité by design de la sécurité a posteriori et repérer laquelle domine dans votre organisation.
- Appliquer les cinq principes fondamentaux de conception sécurisée (moindre privilège, défense en profondeur, échec sécurisé).
- Situer les principes CISA Secure-by-Design et Secure-by-Default, et comprendre ce qui a changé depuis leur publication.
- Chiffrer le coût de correction d'une faille selon le moment où elle est détectée, pour argumenter en interne.
- Relier ces principes au OWASP Top 10:2025 et à ses nouvelles catégories.
- Amorcer une transition concrète vers le security by design dans une équipe existante.
Qu'est-ce que la sécurité by design ?
Section intitulée « Qu'est-ce que la sécurité by design ? »La sécurité by design (ou security by design) consiste à intégrer les exigences de sécurité dès les premières phases d'un projet : conception, architecture, choix technologiques. Ce n'est pas une couche ajoutée, c'est une propriété intrinsèque du système. L'idée rejoint celle du shift-left : plus un problème est traité tôt, moins il coûte cher à corriger.
Cinq principes structurent cette approche :
- Réduction de la surface d'attaque : n'exposer que ce qui est strictement nécessaire.
- Moindre privilège : chaque composant n'a que les droits dont il a besoin, ni plus.
- Défense en profondeur : plusieurs couches de protection indépendantes, pour qu'une seule faille ne compromette pas tout.
- Valeurs par défaut sécurisées : le système est sécurisé sans configuration supplémentaire de l'utilisateur.
- Échec sécurisé : en cas d'erreur, le système refuse l'accès plutôt que de l'autoriser par défaut.
Ces principes ne sont pas des options ajoutées plus tard. Ils façonnent l'architecture dès le départ, ce qui explique pourquoi il est si difficile (et coûteux) de les injecter après coup dans un système déjà construit.
Secure-by-Design vs Secure-by-Default : les principes CISA
Section intitulée « Secure-by-Design vs Secure-by-Default : les principes CISA »En 2023, la CISA (Cybersecurity and Infrastructure Security Agency, l'agence américaine de cybersécurité) et une vingtaine d'agences internationales ont publié le guide "Shifting the Balance of Cybersecurity Risk", qui distingue deux concepts complémentaires.
| Concept | Définition | Responsable | Exemple |
|---|---|---|---|
| Secure-by-Design | La sécurité est intégrée dans l'architecture | Éditeur logiciel | Utilisation de langages memory-safe (Rust, Go) |
| Secure-by-Default | Les configurations par défaut sont sécurisées | Éditeur logiciel | MFA activé par défaut, ports admin fermés |
Depuis, la CISA a transformé ce guide en pledge (engagement volontaire) que des centaines d'éditeurs ont signé : Microsoft, Google, Amazon Web Services, Cisco, Fortinet, ou encore de nombreux fournisseurs plus spécialisés. Le pledge repose sur sept objectifs mesurables que l'éditeur s'engage à progresser sur un an : activer le MFA (authentification multifacteur, une vérification d'identité qui combine mot de passe et second facteur) par défaut, éliminer les mots de passe par défaut, réduire des classes entières de vulnérabilités (par exemple l'injection SQL via des requêtes préparées imposées par le framework), faciliter l'application des correctifs de sécurité, publier une politique de divulgation des vulnérabilités, garantir la complétude des CVE publiées, et fournir des preuves d'intrusion exploitables (logs).
Les éditeurs signataires publient des rapports de progression publics, consultables sur le site de la CISA : c'est un bon indicateur pour évaluer la maturité sécurité d'un fournisseur avant de le choisir.
Quels sont les 3 principes CISA Secure-by-Design ?
Section intitulée « Quels sont les 3 principes CISA Secure-by-Design ? »Au-delà des sept objectifs mesurables du pledge, la CISA formule trois principes directeurs qui s'adressent aux organisations éditrices de logiciels, pas seulement aux produits eux-mêmes. Ils cadrent la responsabilité et la gouvernance de la sécurité, là où les objectifs mesurables cadrent les fonctionnalités.
-
Prendre possession des résultats sécurité du client
L'éditeur logiciel est responsable de la sécurité de son produit, pas le client. Si les utilisateurs subissent des compromissions évitables, c'est un échec du produit, pas une erreur utilisateur.
-
Embrasser la transparence radicale
Publier les CVE, documenter les failles corrigées, partager les pratiques de sécurité internes. La transparence pousse à l'amélioration continue plutôt qu'à la dissimulation.
-
Construire une structure organisationnelle supportive
La sécurité doit être pilotée au niveau exécutif. Les équipes de développement doivent avoir le pouvoir (et le temps) de prioriser la sécurité plutôt que de la sacrifier aux délais.
Différence pratique by-design vs by-default
Section intitulée « Différence pratique by-design vs by-default »Le tableau suivant met les deux notions côte à côte sur des cas concrets, pour lever une confusion fréquente : beaucoup d'équipes pensent avoir fait du security by design en activant simplement des options sécurisées, alors qu'elles n'ont fait que du secure-by-default. Les deux sont utiles, mais seul le premier change l'architecture elle-même.
| Situation | By-Design | By-Default |
|---|---|---|
| Injection SQL | Impossible car l'architecture n'utilise que des requêtes préparées | Non applicable au niveau configuration |
| MFA | Non applicable au niveau architecture | Activé à la création de compte, pas d'option pour le désactiver facilement |
| Accès admin | Architecture sans compte admin partagé (IAM fédéré) | Console admin désactivée par défaut, nécessite configuration explicite |
| Secrets | Architecture où les secrets ne sont jamais dans le code (injection runtime) | Variables d'environnement non loggées par défaut |
| Logs | Événements de sécurité tracés par design (schéma structuré) | Niveau de log INFO par défaut, pas DEBUG |
Qu'est-ce que la sécurité a posteriori ?
Section intitulée « Qu'est-ce que la sécurité a posteriori ? »La sécurité a posteriori est l'approche par défaut dans la plupart des organisations : on développe d'abord un système fonctionnel, puis on y ajoute des mesures de sécurité ensuite. Cette approche semble plus rapide au démarrage, mais elle génère une dette de sécurité qui se paie tôt ou tard, souvent avec des intérêts.
Manifestations courantes :
- Ajout d'un pare-feu applicatif (WAF) devant une application vulnérable.
- Chiffrement ajouté après que les données circulent déjà en clair.
- Audit de sécurité réalisé juste avant la mise en production.
- Correctifs appliqués après découverte d'une faille en production.
- Durcissement d'un serveur déjà en production, sans revoir l'architecture.
Cette approche traite les symptômes plutôt que les causes. Elle crée des couches de protection qui compensent des faiblesses structurelles sans jamais les éliminer, ce qui explique pourquoi les menaces et vulnérabilités reviennent régulièrement sur les mêmes systèmes.
Comparaison des deux approches
Section intitulée « Comparaison des deux approches »Le tableau ci-dessous résume les différences structurelles entre les deux approches. Il aide à objectiver un choix souvent tranché par l'urgence plutôt que par l'analyse : la sécurité a posteriori gagne presque toujours à court terme, la sécurité by design gagne presque toujours à moyen terme.
| Aspect | Sécurité by design | Sécurité a posteriori |
|---|---|---|
| Moment d'intervention | Conception, architecture | Développement tardif, production |
| Coût de correction | Faible (décision de conception) | Élevé (refactoring, patches) |
| Efficacité | Traite les causes | Traite les symptômes |
| Couverture | Systémique | Ponctuelle |
| Maintenabilité | Architecture cohérente | Couches superposées |
| Dette technique | Minimale | Accumulation |
Le coût de la correction selon le moment
Section intitulée « Le coût de la correction selon le moment »Plus une faille est découverte tard dans le cycle de vie, plus elle coûte cher à corriger. Cette progression n'est pas linéaire mais quasi exponentielle, ce qui justifie l'investissement initial dans la conception sécurisée.
| Phase | Coût relatif de correction |
|---|---|
| Conception | 1x |
| Développement | 5x |
| Tests | 10x |
| Production | 30x |
| Après incident | 100x et plus |
Une décision d'architecture prise en 5 minutes peut nécessiter des semaines de refactoring si elle doit être corrigée en production, sans compter le coût de l'incident lui-même s'il a déjà eu lieu.
OWASP Top 10:2025 : la conception sécurisée entre dans le classement
Section intitulée « OWASP Top 10:2025 : la conception sécurisée entre dans le classement »Le OWASP Top 10 liste les dix risques applicatifs les plus critiques, établi à partir de l'analyse de dizaines de milliers de CVE et d'enquêtes auprès de milliers d'organisations. L'édition 2025, annoncée en novembre 2025 et finalisée en janvier 2026, confirme la tendance de fond décrite dans cette page.
Deux nouvelles catégories rejoignent le classement : Software Supply Chain Failures (échecs de la chaîne d'approvisionnement logicielle, qui dépasse la seule gestion des composants vulnérables pour couvrir les compromissions de build, de dépendances et de registre) et Mishandling of Exceptional Conditions (mauvaise gestion des conditions exceptionnelles, c'est-à-dire des erreurs et cas limites mal traités qui produisent un comportement imprévisible).
Ces deux ajouts confirment que les failles les plus coûteuses aujourd'hui ne sont plus seulement des bugs de code isolés, mais des défauts d'architecture et de processus : une chaîne de build sans intégrité vérifiée, une gestion d'erreur qui expose des informations sensibles. Ce sont exactement les catégories que la sécurité by design traite à la racine, quand la sécurité a posteriori ne peut que les masquer par un scanner de plus. Le guide OWASP Top 10 appliqué au DevSecOps détaille chaque catégorie ; le sujet de la chaîne d'approvisionnement logicielle est développé dans Sécurité de la supply chain logicielle.
Exemples concrets
Section intitulée « Exemples concrets »Pour illustrer la différence entre les deux approches, examinons trois domaines où le choix by design vs a posteriori a un impact majeur sur la maintenabilité et le coût réel.
Authentification
Section intitulée « Authentification »By design : l'architecture prévoit dès le départ un service d'authentification centralisé. Toutes les applications l'utilisent. Les tokens sont signés, les sessions gérées uniformément. Ajouter du MFA impacte un seul composant.
A posteriori : chaque application gère sa propre authentification. Certaines stockent les mots de passe en MD5, d'autres en bcrypt, d'autres en clair. Ajouter du MFA nécessite de modifier chaque application. Certaines ne peuvent pas être modifiées (legacy). On ajoute un proxy d'authentification devant, créant une architecture incohérente et un point de défaillance supplémentaire.
Gestion des secrets
Section intitulée « Gestion des secrets »By design : les secrets (clés API, mots de passe) ne sont jamais dans le code source. L'architecture prévoit un gestionnaire de secrets dès le départ. Les applications savent où chercher leurs credentials au démarrage.
A posteriori : les secrets sont dans le code, les fichiers de configuration, les variables d'environnement, parfois en clair dans les logs. On ajoute un gestionnaire de secrets, mais migrer les applications existantes prend des mois. Pendant ce temps, les anciens secrets restent exposés.
Journalisation
Section intitulée « Journalisation »By design : un format de log structuré est défini dès le départ. Chaque événement pertinent pour la sécurité est tracé avec les informations nécessaires (qui, quoi, quand, depuis où). Les logs sont centralisés et indexables.
A posteriori : chaque composant log dans son propre format. Certains en texte, d'autres en JSON, d'autres pas du tout. Après un incident, on découvre qu'il manque des informations critiques. On ajoute des logs, mais l'historique est perdu.
Scénario 1 : l'application legacy
Section intitulée « Scénario 1 : l'application legacy »Une entreprise exploite une application métier développée il y a dix ans. À l'époque, la sécurité n'était pas une priorité. L'application :
- Utilise des requêtes SQL construites par concaténation (injection SQL).
- Stocke les mots de passe en MD5 sans sel.
- Expose une API sans authentification sur le réseau interne.
- Tourne avec un compte administrateur système.
L'équipe sécurité demande une remédiation. Deux options s'affrontent, avec des coûts et des résultats très différents.
Option A, correction a posteriori :
- Ajouter un WAF devant l'application (coût : 2 semaines).
- Forcer le renouvellement des mots de passe (coût : 1 semaine).
- Ajouter une authentification au niveau du reverse proxy (coût : 1 semaine).
- Créer un compte de service dédié (coût : 3 jours).
- Total : environ 1 mois, failles structurelles toujours présentes.
Option B, refonte by design :
- Réécrire les requêtes avec des requêtes préparées.
- Migrer vers bcrypt avec rotation progressive des mots de passe.
- Implémenter une authentification native.
- Appliquer le principe de moindre privilège sur le compte de service.
- Total : environ 3 mois, mais problèmes résolus à la racine.
L'option A est choisie pour des raisons de délai. Deux ans plus tard, une injection SQL est exploitée malgré le WAF, par contournement. Le coût de l'incident dépasse largement celui de la refonte qui avait été écartée.
Scénario 2 : le projet greenfield
Section intitulée « Scénario 2 : le projet greenfield »Une équipe démarre un nouveau projet ("greenfield", c'est-à-dire sans contrainte d'un système existant à faire évoluer). Dès le kickoff, un architecte sécurité participe aux discussions de conception.
Décisions prises en phase de conception :
- Authentification : utilisation d'un provider OIDC (OpenID Connect, un protocole standard qui délègue l'authentification à un service tiers déjà éprouvé) existant, pas de gestion de mots de passe dans l'application.
- Autorisation : modèle RBAC (Role-Based Access Control, un contrôle d'accès basé sur des rôles plutôt que sur des permissions individuelles) défini dans un service dédié, pas de logique d'accès dispersée dans le code.
- Secrets : intégration native avec le gestionnaire de secrets de l'entreprise.
- Logs : format structuré JSON, événements de sécurité définis dans un schéma partagé.
- Données sensibles : chiffrement au repos et en transit, colonnes PII (Personally Identifiable Information, les données qui identifient une personne) identifiées dans le modèle de données dès la conception.
Résultat après 18 mois :
- Zéro faille critique découverte lors des audits.
- Conformité réglementaire obtenue sans effort supplémentaire.
- Temps de réponse aux incidents réduit grâce aux logs exploitables.
- Coût de maintenance sécurité intégré dans le développement normal, sans ligne budgétaire séparée.
Comment passer au security by design
Section intitulée « Comment passer au security by design »Impliquer la sécurité dès le début
Section intitulée « Impliquer la sécurité dès le début »La sécurité n'est pas une validation finale. Elle participe aux :
- Revues d'architecture : identifier les risques structurels avant qu'ils ne soient codés.
- Choix technologiques : évaluer la posture sécurité des composants (langage memory-safe, framework avec requêtes préparées par défaut).
- Définitions des stories : inclure les critères de sécurité dans la définition du "fini" ("Definition of Done").
Définir des standards
Section intitulée « Définir des standards »Plutôt que de réinventer à chaque projet, une organisation gagne à documenter :
- Des patterns d'authentification approuvés.
- Des méthodes de gestion des secrets standardisées.
- Un format de journalisation commun à tous les services.
- Une checklist de conception sécurisée utilisée en revue d'architecture.
Automatiser les vérifications
Section intitulée « Automatiser les vérifications »Intégrer les contrôles dans le pipeline transforme la sécurité en garde-fou continu plutôt qu'en audit ponctuel :
- Analyse statique du code (SAST, Static Application Security Testing, qui repère les failles en lisant le code sans l'exécuter).
- Scan des dépendances vulnérables.
- Vérification des configurations (IaC, Infrastructure as Code, l'infrastructure décrite dans des fichiers versionnés plutôt que configurée à la main).
- Tests de sécurité automatisés en intégration continue.
Ces contrôles détectent les régressions avant qu'elles n'atteignent la production, ce qui rejoint directement la logique du pipeline CI/CD sécurisé.
À retenir
Section intitulée « À retenir »-
La sécurité by design intègre la protection dès la conception, elle traite les causes plutôt que les symptômes et produit des systèmes naturellement robustes.
-
Secure-by-Design et Secure-by-Default sont complémentaires : l'un façonne l'architecture, l'autre les configurations par défaut.
-
Le pledge CISA repose sur sept objectifs mesurables (MFA par défaut, suppression des mots de passe par défaut, réduction de classes de vulnérabilités, patchs, divulgation, CVE, logs d'intrusion), suivis par des rapports de progression publics.
-
Le coût de correction augmente quasi exponentiellement avec le temps : une faille corrigée en conception coûte 1, en production elle coûte 30 ou plus.
-
Le OWASP Top 10:2025 confirme la tendance : deux nouvelles catégories, Software Supply Chain Failures et Mishandling of Exceptional Conditions, sont des défauts d'architecture, pas de simples bugs.
-
Les systèmes legacy accumulent une dette de sécurité : chaque patch ajouté complexifie l'architecture sans éliminer les risques fondamentaux.
-
Passer au security by design nécessite un changement culturel : impliquer la sécurité dès le début, définir des standards, automatiser les vérifications dans le pipeline.
Ressources
Section intitulée « Ressources »- CISA Secure by Design, Guide officiel avec les 3 principes et le pledge
- Secure by Design Pledge, rapports de progression, Suivi public des engagements des éditeurs signataires
- OWASP Top 10:2025, Édition finalisée en janvier 2026, avec ses deux nouvelles catégories
- CWE Top 25, Les 25 faiblesses logicielles les plus dangereuses