01Secure by design vs secure by default
Secure by design décrit la manière dont un système est construit : les menaces sont modélisées tôt, et les patterns d'architecture, une cryptographie éprouvée et une gestion systématique des vulnérabilités sont intégrés au processus de développement plutôt qu'ajoutés après coup. Secure by default décrit la manière dont le produit arrive chez le client : livré dans la configuration la plus sûre raisonnablement possible, sans exiger d'expertise – les protections sont actives, et les affaiblir suppose une décision délibérée. Le playbook organise les 14 principes de conception en Architectural Foundations et Operational Integrity, et les 8 principes par défaut en Default Hardening et Guided Protection.
02Les 22 principes en un coup d'œil
Architectural Foundations (6) couvre les trust boundaries et le threat modelling, le moindre privilège, une architecture d'identité et d'authentification robuste, la minimisation de la surface d'attaque, la défense en profondeur et l'open design. Operational Integrity (8) ajoute la gestion du cycle de vie, la conception centrée utilisateur, le codage sécurisé et la vérification, la journalisation et la supervision, la gestion des configurations et des changements, la réponse aux incidents, la gestion des vulnérabilités et des correctifs ainsi que les contrôles de la chaîne d'approvisionnement, SBOM compris. Côté défaut figurent la minimisation des services par défaut, un accès initial restrictif, la communication chiffrée d'usine et des identités d'appareil uniques (Default Hardening), ainsi qu'un onboarding sécurité obligatoire, les mises à jour automatiques, une posture de sécurité transparente et des processus sûrs de récupération et de transfert de propriété (Guided Protection).
03Anatomie d'un playbook : check-list, preuves, release gate
Chaque principe suit le même format en cinq blocs : principe, objectif, check-list des actions à plus fort impact, preuves minimales – le plus petit ensemble d'artefacts démontrant la mise en œuvre – et un release gate avec des critères pass/fail pour les revues de release ou la chaîne CI/CD. Les preuves doivent provenir d'artefacts d'ingénierie existants (diagrammes d'architecture, logs CI, tickets, SBOM) et peuvent servir plusieurs playbooks à la fois ; les exceptions sont permises, mais uniquement documentées avec un responsable et une date de revue. Pour l'adoption, l'ENISA propose trois étapes : clarifier d'abord le contexte et les priorités, établir ensuite une base d'ingénierie – codage sécurisé, journalisation, gestion des vulnérabilités et contrôles de la supply chain, complétés par les playbooks par défaut pertinents pour le produit – puis élargir la couverture et l'automatisation. Point important : ce séquencement organise l'effort, il ne diffère aucune obligation légale.
04Threat modelling en mode léger
Plutôt que des analyses lourdes, le playbook recommande un minimum viable threat model articulé autour des quatre questions du framework de Shostack : sur quoi travaillons-nous ? Qu'est-ce qui peut mal tourner ? Qu'allons-nous faire ? Avons-nous fait du bon travail ? Le résultat tient sur une page : un diagramme avec composants, flux de données et trust boundaries, les cinq à dix scénarios de menace les plus pertinents, pour chacun les contrôles avec réglages secure-default et méthodes de vérification – plus des déclencheurs définis pour rafraîchir le modèle. L'ENISA nomme explicitement les anti-patterns typiques : le threat modelling comme exercice de conformité ponctuel, des modèles sur-détaillés sans effet sur les décisions de conception, et l'absence de mise à jour après des changements produit. Pour les produits intégrant de l'IA, la prompt injection, l'empoisonnement de modèle et les entrées adversariales font aussi partie du modèle.
05Attestation lisible par machine : la conformité as code
La partie la plus prospective du document : les affirmations de sécurité quittent les PDF statiques pour des artefacts structurés et signables (JSON/YAML) reliant trois couches – objectifs de sécurité (control layer), contrôles mis en œuvre et leur configuration (implementation layer), et résultats de vérification automatisés avec hachages de preuves (assessment and verification layer). À travers l'exemple travaillé SafeGate-X1, un contrôleur industriel sous Linux, l'ENISA montre comment les menaces deviennent traçables des principes jusqu'aux release gates automatiques – du gate de scan Nmap au test de système de fichiers en lecture seule dans la CI. L'ENISA n'impose délibérément aucun nouveau schéma et renvoie aux standards existants : NIST OSCAL, OWASP CycloneDX avec CDXA et VEX, le profil sécurité SPDX 3.0, les projets OpenSSF comme Scorecard et SLSA, ainsi qu'in-toto et Sigstore. Une clarification s'impose : une attestation du fabricant n'est pas une preuve – la vérification et l'évaluation indépendante restent des étapes distinctes.
06Le pont vers le CRA : l'annexe C
L'annexe B du playbook reprend les exigences essentielles de cybersécurité de l'annexe I du Cyber Resilience Act ; l'annexe C y rattache chacun des 22 principes de manière indicative – les mises à jour automatiques à l'annexe I partie I 2(c), les contrôles de la supply chain à l'obligation de SBOM de la partie II, ou l'accès initial restrictif à la configuration par défaut sécurisée de la partie I 2(b). Le document constitue ainsi une porte d'entrée d'ingénierie utile pour les gap analyses CRA : les équipes voient quels playbooks alimentent quelles exigences et collectent tôt des preuves solides via les release gates. L'ENISA souligne en même temps que suivre le playbook n'établit pas la conformité au CRA – l'évaluation de la conformité, les normes harmonisées et la documentation technique exigée par le règlement restent des obligations distinctes.
Deep dive : Cyber Resilience Act de l'UE → 
