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. Ce guide compare ces deux approches et montre pourquoi la sécurité by design est presque toujours préférable.
En résumé : La sécurité by design intègre la protection dès la conception (architecture, choix techniques). La sécurité a posteriori ajoute des couches de protection sur un système déjà construit. La première coûte moins cher et produit des systèmes plus robustes.
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.
Principes fondamentaux :
- 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
- Défense en profondeur : plusieurs couches de protection indépendantes
- Valeurs par défaut sécurisées : le système est sécurisé sans configuration supplémentaire
- Échec sécurisé : en cas d’erreur, le système refuse l’accès plutôt que de l’autoriser
Ces principes ne sont pas des options ajoutées plus tard. Ils façonnent l’architecture dès le départ.
Secure-by-Design vs Secure-by-Default (CISA 2025)
Section intitulée « Secure-by-Design vs Secure-by-Default (CISA 2025) »En 2023-2025, la CISA (Cybersecurity & Infrastructure Security Agency) et 17 agences internationales ont publié le guide “Shifting the Balance of Cybersecurity Risk”. Ce guide 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 |
Les 3 principes CISA Secure-by-Design
Section intitulée « Les 3 principes CISA Secure-by-Design »-
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.
-
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é.
Différence pratique by-design vs by-default
Section intitulée « Différence pratique by-design vs by-default »| Situation | By-Design | By-Default |
|---|---|---|
| Injection SQL | Impossible car l’architecture n’utilise que des requêtes préparées | — |
| MFA | — | 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 mais génère une dette de sécurité qui se paie tôt ou tard.
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
- Durcissement d’un serveur déjà en production
Cette approche traite les symptômes plutôt que les causes. Elle crée des couches de protection qui compensent des faiblesses structurelles.
Comparaison des deux approches
Section intitulée « Comparaison des deux approches »| 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, plus elle coûte cher à corriger :
| Phase | Coût relatif de correction |
|---|---|
| Conception | 1x |
| Développement | 5x |
| Tests | 10x |
| Production | 30x |
| Après incident | 100x+ |
Une décision d’architecture prise en 5 minutes peut nécessiter des semaines de refactoring si elle doit être corrigée en production.
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.
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.
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.
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 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 10 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. Options :
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 : ~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
- Implémenter une authentification native
- Appliquer le principe de moindre privilège
- Total : ~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 (contournement). Le coût de l’incident dépasse largement celui de la refonte.
Scénario 2 : Le projet greenfield
Section intitulée « Scénario 2 : Le projet greenfield »Une équipe démarre un nouveau projet. Dès le kickoff, un architecte sécurité participe aux discussions.
Décisions prises en phase de conception :
- Authentification : utilisation d’un provider OIDC existant, pas de gestion de mots de passe dans l’application
- Autorisation : modèle RBAC 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 identifiées dans le modèle de données
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
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
- Choix technologiques : évaluer la posture sécurité des composants
- Définitions des stories : inclure les critères de sécurité dans le “done”
Définir des standards
Section intitulée « Définir des standards »Plutôt que de réinventer à chaque projet :
- Patterns d’authentification approuvés
- Méthodes de gestion des secrets standardisées
- Format de journalisation commun
- Checklist de conception sécurisée
Automatiser les vérifications
Section intitulée « Automatiser les vérifications »Intégrer les contrôles dans le pipeline :
- Analyse statique du code (SAST)
- Scan des dépendances vulnérables
- Vérification des configurations (IaC)
- Tests de sécurité automatisés
Ces contrôles détectent les régressions avant qu’elles n’atteignent la production.
À 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 + Secure-by-Default sont complémentaires — l’un façonne l’architecture, l’autre les configurations par défaut.
-
La CISA recommande trois principes — prendre possession des résultats sécurité, transparence radicale, structure organisationnelle supportive.
-
Le coût de correction augmente exponentiellement avec le temps — une faille corrigée en conception coûte 1, en production elle coûte 30 ou plus.
-
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.
Ressources
Section intitulée « Ressources »- CISA Secure-by-Design — Guide officiel avec les 3 principes
- Shifting the Balance of Cybersecurity Risk (PDF) — Document complet CISA + 17 agences internationales
- OWASP Top 10 — Les 10 failles applicatives les plus courantes
- CWE Top 25 — Les 25 faiblesses logicielles les plus dangereuses