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, situe chaque contrôle dans le cycle de développement sécurisé (Secure SDLC), 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é).
- Comparer les principes CISA Secure-by-Design et Secure-by-Default, et comprendre ce qui a changé depuis leur publication.
- Situer chaque contrôle dans le cycle de développement sécurisé (Secure SDLC), et argumenter le coût d'une correction tardive sans multiplicateur invérifiable.
- 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.
Où la sécurité entre-t-elle dans le cycle de développement ?
Section intitulée « Où la sécurité entre-t-elle dans le cycle de développement ? »Le Secure SDLC (Secure Software Development Life Cycle, le cycle de développement sécurisé) est la forme concrète de la sécurité by design : chaque étape du cycle porte sa question de sécurité et son contrôle, au lieu d'un audit unique en fin de projet. Les étapes ci-dessous suivent celles du processus de l'OWASP DevSecOps Guideline, de la conception à l'exploitation, précédées de l'expression des exigences. La dernière colonne indique où la formation DevSecOps enseigne chaque contrôle.
| Étape | Question de sécurité | Contrôle typique | Où l'apprendre |
|---|---|---|---|
| Exigences | Que doit garantir le système ? | Critères de sécurité dans la Definition of Done | cette leçon |
| Conception | Que protège-t-on, et contre qui ? | Modèle de menace, revue d'architecture | Threat modeling avec STRIDE |
| Code | Une faille ou un secret entre-t-il dans le dépôt ? | Pre-commit, SAST, détection de secrets | Gitleaks, Semgrep |
| Build | Les dépendances et l'image sont-elles saines ? | SCA, scan d'image, scan IaC | SCA, Checkov |
| Test | L'application démarrée résiste-t-elle ? | DAST, tests de sécurité en CI | DAST |
| Release | Que livre-t-on, et qui l'a construit ? | SBOM, signature, provenance | SBOM, Cosign |
| Déploiement | Qu'est-ce qui a le droit de s'exécuter, avec quels droits ? | Gates, identités courtes, politique d'admission | Pipeline sécurisé, workload identity |
| Exploitation | Que se passe-t-il en production ? | Détection runtime, gestion des vulnérabilités | Sécurité des conteneurs, gestion des CVE |
Deux erreurs courantes se lisent directement dans ce tableau. La première consiste à tout concentrer sur la ligne Test, un scan juste avant la release : c'est la définition même de la sécurité a posteriori. La seconde consiste à sauter les lignes Exigences et Conception, parce qu'elles ne produisent aucune alerte d'outil ; ce sont pourtant les seules où corriger ne coûte qu'une décision.
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 |
En mai 2024, la CISA a prolongé ce guide par un pledge (engagement volontaire), signé par 68 éditeurs au lancement, dont Microsoft, Google, Amazon Web Services, Cisco et Fortinet, et par plus de 250 à la fin de 2024. 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, et chaque étape franchie ajoute des gestes au correctif. Les multiplicateurs chiffrés qui circulent (x5, x30, x100) n'ont en revanche aucune source vérifiable, comme le montre la leçon Shift-Left : on raisonne donc sur ce que chaque étape ajoute, pas sur un coefficient.
| Phase | Ce que la correction implique |
|---|---|
| Conception | Changer un schéma ou une décision d'architecture |
| Développement | Réécrire un module, relancer les tests |
| Tests | Corriger, puis rejouer la non-régression |
| Production | Correctif d'urgence, redéploiement, fenêtre d'exposition |
| Après incident | Investigation, communication, obligations réglementaires, perte de confiance |
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 à chaque étape franchie : une décision de conception se corrige en changeant un schéma, la même faille en production exige correctif d'urgence et redéploiement. Les multiplicateurs chiffrés qui circulent ne sont pas sourcés.
-
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.
Contrôle de connaissances
Section intitulée « Contrôle de connaissances »Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Continuer le cours : Shift-Left : détecter les problèmes au plus tôt
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications
Ressources
Section intitulée « Ressources »Ces références officielles permettent de vérifier chaque affirmation de la page à la source, et de suivre leur évolution : le pledge CISA publie ses rapports de progression, l'OWASP révise son classement tous les trois à quatre ans.
- 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
- OWASP DevSecOps Guideline, Les étapes du processus (Design à Operate) reprises dans le tableau du Secure SDLC
- CWE Top 25, Les 25 faiblesses logicielles les plus dangereuses
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Ces réponses courtes reprennent les questions qui reviennent le plus souvent sur la sécurité by design : principes CISA, coût d'une correction tardive, transition d'une équipe. Chacune se lit seule.