Le Playbook Secure by Design de l'ENISA : ce que cela signifie pour les équipes produit sous le CRA

Qu'est-ce que le Playbook Secure by Design de l'ENISA ?

Le 19 mars 2026, l'Agence de l'Union européenne pour la cybersécurité (ENISA) a publié le Security by Design and Default Playbook, version 0.4, sous forme de projet soumis à consultation publique.

C'est le premier guide officiel de l'UE qui traduit les exigences de sécurité du CRA en listes de contrôle d'ingénierie concrètes destinées aux PME. Ce document n'est pas un guide juridique. Il propose des approches pratiques et techniquement fondées que les équipes produit peuvent appliquer pendant les phases de conception, de développement et de déploiement.

Le playbook cible les PME (définies comme les organisations de moins de 250 salariés et dont le chiffre d'affaires annuel est inférieur à 50 millions d'euros) qui fabriquent des produits comportant des éléments numériques. Cela inclut les logiciels embarqués, les appareils IoT, les systèmes connectés, les logiciels autonomes et le matériel avec des composants programmables.

L'ENISA a développé ce playbook à partir d'une analyse des référentiels de sécurité existants publiés par l'ENISA et d'autres agences européennes de cybersécurité, ainsi que des guides du NIST et d'OWASP. Les exigences communes et les modèles de mise en oeuvre ont été identifiés et évalués au regard des capacités des PME pour déterminer la faisabilité et les besoins d'adaptation.

L'Annexe C du playbook associe les 22 principes directement aux exigences essentielles de l'Annexe I du CRA, établissant un lien traçable entre les pratiques d'ingénierie et les obligations réglementaires.

Important : Il s'agit d'un projet soumis à consultation publique (v0.4). L'ENISA recueille activement des retours. La version finale pourra différer.

À qui s'adresse ce playbook ?

Le playbook identifie quatre groupes principaux (Section 1.3) :

• Développeurs et ingénieurs logiciels : les personnes qui écrivent du code et ont besoin de méthodes pratiques pour intégrer la sécurité sans ralentir les livraisons
• Chefs de produit techniques : les personnes qui équilibrent le développement de fonctionnalités et les exigences de sécurité, en cherchant à concilier les deux
• Responsables sécurité PME : les personnes qui traduisent des référentiels de niveau entreprise en quelque chose qui fonctionne avec des budgets limités et de petites équipes
• Architectes système : les personnes qui conçoivent des systèmes et souhaitent que la sécurité soit intégrée dès le départ, et non ajoutée après coup

Le défi commun que l'ENISA reconnaît : la plupart des PME n'ont pas d'équipe de sécurité dédiée, un budget limité pour les outils de sécurité, et un travail de sécurité qui est en permanence en concurrence avec la livraison de fonctionnalités.

La réponse du playbook : des listes de contrôle structurées qui aident les équipes à identifier les contrôles de sécurité à fort impact rapide, à les mettre en oeuvre de façon réaliste, et à construire une base reproductible qu'elles peuvent améliorer avec le temps.

La sécurité tout au long du cycle de vie du produit

La sécurité doit être prise en compte de bout en bout, quel que soit le modèle de production utilisé (modèle en V, Agile ou autre). Le playbook définit six phases, chacune avec des actions de sécurité spécifiques et des livrables concrets.

Principes clés du document :

• Utiliser des artefacts petits et réutilisables (notes de contexte d'une page, diagrammes simples, listes de contrôle)
• Préférer les contrôles automatisés en CI/CD aux revues manuelles, en réservant les revues approfondies aux changements à risque élevé
• Introduire des portes de sécurité rapides alignées sur les cérémonies agile existantes (Definition of Ready/Done, vérifications de PR, checklist de publication)

Chaque phase produit un livrable concret. Ce guide n'est pas abstrait.

Conseil : Le playbook recommande de garder les artefacts du cycle de vie légers : une note de contexte de sécurité d'une page, un diagramme d'architecture simple et une checklist de publication suffisent pour commencer.

Quelles activités de gestion des risques l'ENISA recommande-t-elle ?

Les activités de gestion des risques constituent le socle de toutes les décisions Secure by Design et Secure by Default. Le playbook ne propose pas un référentiel formel lourd. Il définit un ensemble minimum d'activités qui peuvent orienter les décisions de sécurité sans créer de processus pesant (Section 2.2).

Le document définit 8 activités (Tableau 2) :

1. Contexte et périmètre du produit : Définir l'utilisation prévue, les environnements de déploiement, les rôles utilisateurs et administrateurs, les types de données et leur sensibilité, et les dépendances externes clés. Livrable : note "Product Security Context" de 1 à 2 pages (périmètre, hypothèses, dépendances).
2. Identification des actifs et des préjudices : Lister les principaux actifs de données, matériels ou fonctionnels (identifiants, données clients, DCP, contrôle d'appareils) et les principaux préjudices potentiels (violation de la vie privée, prise de contrôle, interruption de service, fraude, impact sur la sécurité). Livrable : liste des actifs + liste des "principaux préjudices" (une page).
3. Modélisation légère des menaces : voir la section sur la modélisation des menaces ci-dessous.
4. Registre des risques : Enregistrer 10 à 30 risques avec leur probabilité et impact (échelle simple), leur responsable, leur traitement et leur statut. Lier les risques élevés aux éléments du backlog et aux contrôles. Livrable : registre des risques évolutif (tableur ou tableau de tickets).
5. Critères d'acceptation des risques : Définir un ensemble de conditions de risque non négociables. Par exemple : l'abus des mises à jour logicielles, l'accès administratif non autorisé ou l'exploitation des identifiants par défaut ne sont PAS acceptables. Établir des critères pour accepter les risques résiduels qui ne doivent pas compromettre les exigences essentielles de cybersécurité. Livrable : politique d'acceptation des risques et d'exceptions d'une page.
6. Référentiel des exigences de sécurité : Traduire les principaux risques en exigences "must" testables (authn/authz, valeurs par défaut sécurisées, secrets, chiffrement, journalisation, mises à jour). Livrable : checklist des exigences de sécurité PME (contrôles testables).
7. Porte de revue des risques avant publication : Porte formelle pré-publication : confirmer que la checklist est respectée, les valeurs par défaut vérifiées, les vulnérabilités connues triées, les risques élevés traités ou acceptés avec justification. Décider de publier ou non. Livrable : compte-rendu de revue de sécurité de publication + exceptions documentées.
8. Réévaluation déclenchée par les changements : Relancer les étapes contexte/menaces/risques lors de changements majeurs (architecture, modèle d'authentification, dépendance ou fournisseur critique, environnement de déploiement, après des incidents). Livrable : note de contexte mise à jour, liste courte de menaces et entrées du registre des risques (avec date).

Note : La gestion des risques est itérative, pas ponctuelle. Le playbook précise qu'elle doit être revue à des portes de cycle de vie définies et déclenchée par des événements significatifs (publication majeure, changement de fournisseur, nouveau contexte de déploiement, retours d'incidents).

Comment les PME doivent-elles aborder la modélisation des menaces ?

Le playbook s'appuie sur la méthodologie STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) comme base pour l'identification et la classification des menaces (Section 2.3).

Il met explicitement en garde contre les anti-patterns courants : traiter la modélisation des menaces comme un exercice de conformité ponctuel, créer des modèles trop complexes qui n'influencent pas les décisions de conception ou de configuration sécurisée par défaut, et ne pas revoir le modèle après des modifications substantielles du produit ou des changements dans le paysage des menaces.

Pour les PME, en particulier celles qui développent des produits destinés à des environnements non critiques ou à faible risque, l'objectif est un modèle "minimum viable" : rapide à produire, facile à actualiser, et étroitement lié à la livraison (décisions d'architecture, configuration par défaut, et portes de publication).

Les 5 étapes (Tableau 3)

1. Définir le périmètre, les hypothèses et les objectifs de sécurité : Délimiter dans le temps l'étape de cadrage. Capturer ce qui est dans ou hors du périmètre, le contexte de déploiement, et les hypothèses sur lesquelles on s'appuie (par exemple, "le réseau client n'est pas fiable", "les API cloud sont exposées sur internet"). Énoncer les objectifs de sécurité qui comptent pour ce produit (confidentialité, intégrité, disponibilité, plus vie privée et sécurité physique si applicable). Identifier les "joyaux de la couronne" : ce qui ne doit pas tomber. Livrable : "Threat Model Scope & Objectives" d'une page.

2. Modéliser le système à un niveau d'abstraction utile : Produire un seul diagramme d'architecture ou de flux de données simple. Montrer les composants principaux, les entités externes, les magasins de données, ainsi que les principaux points d'entrée et flux de données. Un diagramme de style DFD est l'approche la plus rapide et la plus utile. Le document dit "ne pas trop réfléchir". Livrable : diagramme couvrant les composants principaux, entités externes, magasins de données, points d'entrée.

3. Marquer les frontières de confiance et les chemins privilégiés, identifier les actifs clés : Annoter le diagramme avec les frontières de confiance (internet-backend, appareil-cloud, utilisateur-admin, tenant-tenant) et les opérations les plus privilégiées (mise à jour firmware/OTA, administration à distance, provisionnement de clés, émission d'identités). Cette étape transforme "l'architecture" en "architecture pertinente pour la sécurité". Livrable : diagramme avec frontières de confiance, chemins privilégiés, principaux actifs.

4. Identifier et prioriser les principales menaces (5 à 10 cas d'abus) : Générer une courte liste de cas d'abus réalistes associés aux points d'entrée et aux frontières (par exemple, "credential stuffing vers prise de contrôle de compte", "mise à jour malveillante", "contournement d'autorisation API", "MITM à l'onboarding"). Les classer avec un schéma léger (Élevé/Moyen/Faible) basé sur l'impact et la plausibilité. OWASP décrit l'identification et le classement des menaces comme une étape centrale de la plupart des approches de modélisation des menaces. Livrable : tableau des menaces principales avec 5 à 10 cas d'abus, impact + probabilité, liste des "principaux risques".

5. Définir les atténuations, les valeurs par défaut sécurisées et la vérification ; fixer les déclencheurs de mise à jour : Pour chaque menace principale, spécifier la stratégie d'atténuation, les contrôles requis, et la configuration sécurisée par défaut qui doit être livrée (par exemple, "interface admin désactivée par défaut", "pas de mots de passe par défaut", "mises à jour signées imposées", "rôles à privilège minimal", "tentatives d'authentification limitées en débit"). Associer chaque contrôle à une méthode de vérification (vérifications CI, tests, validation de configuration, porte de publication). Définir les déclencheurs qui nécessitent de relancer le modèle (nouvelle interface exposée sur internet, changement du modèle d'authentification, nouvelles données sensibles, nouvelle dépendance critique, changement d'architecture majeur). Livrable : checklist Contrôles, Valeurs par défaut et Vérification.

Conseil : Même 2 heures de modélisation collaborative des menaces avec votre équipe produisent des résultats exploitables. Le document insiste sur le "minimum viable". Vous pourrez toujours affiner par la suite.

Quels sont les 22 principes de sécurité ?

Le document définit 22 principes de sécurité (Section 3), chacun disposant de son propre playbook d'une page dans la Section 4. Les playbooks constituent le livrable central du document. Chacun distille un seul principe en un guide orienté vers l'exécution, avec une liste de contrôle, des preuves minimales et des critères de porte de publication. Les principes sont organisés en deux piliers : Secure by Design (comment le système est conçu, 14 principes) et Secure by Default (comment le produit arrive et se comporte à la première mise en route, 8 principes). Chaque pilier est subdivisé en deux groupes.

Fondations architecturales (6 principes)

Ces principes portent sur la conception et la construction structurelle du système :

1. Frontières de confiance et modélisation des menaces : Rendre la confiance explicite. Définir où les données, les identités et les contextes d'exécution franchissent la frontière entre zones fiables et non fiables. Modéliser les menaces pour identifier ce qui pourrait mal tourner à ces frontières.
2. Moindre privilège : N'accorder que l'accès minimum requis. Appliquer de façon cohérente aux comptes utilisateurs, aux comptes de service, aux API et aux rôles d'administration. Élever les privilèges uniquement quand c'est nécessaire, pour la durée la plus courte possible.
3. Architecture d'identité forte et d'authentification : Approche claire sur la façon dont les identités sont créées, vérifiées et gérées pour les utilisateurs, les appareils, les services et les administrateurs. Résistante au credential stuffing, au rejeu et au détournement de session.
4. Minimisation de la surface d'attaque : Réduire la complexité. Supprimer les comptes par défaut, désinstaller les paquets inutilisés, fermer les ports non essentiels, limiter les interfaces de gestion exposées. Analyse de vulnérabilités continue.
5. Défense en profondeur : Contrôles superposés pour qu'une défaillance d'un contrôle ne signifie pas une compromission totale. Contrôles préventifs, détectifs et correctifs. Divers et indépendants, ne reposant pas tous sur la même technologie ou hypothèse de confiance.
6. Open Design (éviter l'obscurité) : Ne pas dépendre du secret de la conception pour la protection. Utiliser des algorithmes et protocoles bien étudiés, une documentation claire, et des conceptions qui résistent à l'examen. La sécurité doit reposer sur des clés protégées, une authentification forte et une implémentation robuste, et non sur des mécanismes cachés.

Intégrité opérationnelle (8 principes)

Ces principes portent sur la gestion et la maintenance du système :

1. Gestion du cycle de vie : La sécurité s'étend au-delà du développement. Maintenir, mettre à jour et retirer de façon contrôlée. Appliquer le Secure by Design depuis le développement jusqu'au retrait du marché.
2. Conception centrée sur l'utilisateur : La sécurité doit être utilisable par les utilisateurs du quotidien. Une mauvaise utilisabilité conduit à des contournements non sécurisés. Configuration simple, chiffrement automatique, flux guidés.
3. Pratiques de codage sécurisé : Suivre les standards de codage sécurisé établis. Outils SAST, SCA pour les dépendances, DAST avant le déploiement. Identification précoce, pas après la publication.
4. Journalisation, surveillance et alertes : Générer des journaux pertinents pour la sécurité, les conserver pendant une période définie, et les protéger contre toute altération. Détecter les comportements suspects (authentification échouée, élévation de privilèges, changements de configuration inattendus).
5. Gestion de la configuration et des changements : Les configurations doivent être contrôlées, cohérentes et auditables. Durcissement de base, infrastructure-as-code, processus de changement avec revue, test, approbation et retour arrière.
6. Réponse aux incidents et rétablissement : Préparé aux vulnérabilités, au code compromis, aux mises à jour malveillantes, aux mauvais usages du produit. Rôles définis, chemins d'escalade, playbooks documentés, communication client.
7. Gestion des vulnérabilités et des correctifs : Pratique, reproductible, priorisée par le risque. Canal d'entrée simple (email de sécurité + processus de divulgation), processus de triage interne, SLA clairs.
8. Contrôles de la chaîne d'approvisionnement : Protéger l'intégrité du produit aux points à plus fort impact : dépôts de code, systèmes de build, clés de signature, canaux de distribution. Au minimum : accès CI/CD limité, MFA, revue par les pairs pour les changements critiques pour la sécurité, SBOM.

Durcissement par défaut (4 principes)

Ces principes garantissent que les produits démarrent dans un état sécurisé et restrictif :

1. Minimisation des services par défaut : Les fonctionnalités et services non essentiels sont désactivés par défaut. L'utilisateur doit explicitement les activer.
2. Accès initial restrictif : Éliminer les identifiants universels "admin/admin". Imposer des mots de passe uniques et un changement de mot de passe obligatoire au premier démarrage.
3. Communications sécurisées par défaut : Toutes les communications externes sont chiffrées et authentifiées dès la première connexion. Imposer strictement TLS 1.3 ou SSH. Pas de replis HTTP/Telnet.
4. Identité et secrets uniques par appareil par défaut : Livrer avec des identifiants uniques par appareil et une identité cryptographique. Pas de clés ou certificats partagés entre produits. Protégés contre l'extraction.

Protection guidée (4 principes)

Ces principes aident les utilisateurs à maintenir la sécurité après le déploiement :

1. Onboarding de sécurité obligatoire : Les fonctionnalités de sécurité critiques doivent faire partie de l'assistant de configuration initial (MFA, clé de chiffrement, configuration du compte admin). Ne pas les cacher dans les paramètres. Bloquer l'utilisation tant qu'elles ne sont pas complétées.
2. Maintenance et mises à jour automatiques : Mises à jour de sécurité automatiques activées par défaut. Séparer les mises à jour de sécurité des mises à jour de fonctionnalités. Vérifiées cryptographiquement. Modes d'échec sûrs (ne pas rendre l'appareil inutilisable). Notifier les utilisateurs.
3. Posture de sécurité transparente : Afficher clairement l'état de sécurité actuel. Avertir lorsque l'utilisateur réduit la sécurité. Expliquer l'impact en langage clair. Proposer un chemin en un clic pour restaurer la configuration sécurisée de base.
4. Rétablissement sécurisé et cycle de vie de propriété : Rétablissement guidé (réinitialisation des identifiants, récupération de compte, remise aux paramètres d'usine, transfert de propriété). Simple pour les utilisateurs mais résistant à la prise de contrôle de compte et à l'ingénierie sociale. La remise aux paramètres d'usine doit supprimer complètement les accès de l'utilisateur précédent.

Lien CRA : L'Annexe C du playbook associe chacun de ces 22 principes à des exigences essentielles spécifiques de l'Annexe I du CRA, montrant exactement quelles pratiques d'ingénierie soutiennent quelles obligations légales.

Comment fonctionnent les playbooks ?

Le format du playbook

La Section 4 est la partie la plus étendue du document. Elle fournit un moyen pratique et léger pour les PME d'implémenter le Security by Design and Default sans créer une charge de gouvernance lourde. Chaque playbook distille un seul principe de sécurité en un guide d'une page, orienté vers l'exécution, que les équipes peuvent appliquer de façon répétée à travers les publications et les lignes de produits (Section 4, p28).

L'intention est de traduire les principes de sécurité d'aspirations abstraites en actions d'ingénierie et opérationnelles concrètes, avec des attentes claires, des résultats vérifiables, et une "définition de done" cohérente pour la sécurité. Chaque playbook suit le même format en cinq sections :

• Nom du principe : le concept de sécurité mis en oeuvre
• Objectif : ce que le principe cherche à atteindre et quels modes de défaillance il réduit
• Liste de contrôle : les actions à fort impact à implémenter (conçues pour être réalisables par des équipes légères)
• Preuves minimales : le plus petit ensemble d'artefacts, journaux ou configurations démontrant que la liste de contrôle a été mise en oeuvre
• Porte de publication : un ensemble de critères réussite/échec prêts à l'emploi, utilisables dans une revue de publication ou en CI/CD pour prévenir les régressions

Important : Cette structure est délibérément alignée sur le fonctionnement des PME : cycles courts, responsabilités partagées, capacité spécialisée limitée, et besoin d'un guide à fort rapport signal/bruit.

Utiliser les playbooks

• Traiter la porte de publication de chaque playbook comme un point à l'ordre du jour standard des revues de disponibilité à la publication
• Implémenter les preuves minimales sous forme d'artefacts de dépôt et de sorties CI dans la mesure du possible
• N'autoriser les exceptions qu'avec une justification documentée, un responsable et une date de révision
• Actualiser les playbooks périodiquement en fonction des retours d'incidents, des tendances en matière de vulnérabilités et des évolutions du produit
• Le contenu doit être traité comme une base de référence, pas comme un état final. Réviser et mettre à jour au fur et à mesure que les produits évoluent.

Les 22 playbooks en un coup d'oeil

Fondations architecturales :

Intégrité opérationnelle :

Durcissement par défaut :

Protection guidée :

Approfondissement : Playbook 4.13, Gestion des vulnérabilités et des correctifs

Pour illustrer la profondeur pratique du format, voici le Playbook 4.13 dans son intégralité tel qu'il apparaît dans le document :

Principe : La gestion des vulnérabilités et des correctifs doit être pratique, reproductible et priorisée par le risque. Les fabricants ont besoin d'un moyen simple pour que les clients et les chercheurs puissent signaler des problèmes, et d'un processus interne pour trier rapidement les découvertes et décider de ce qui nécessite une action urgente.

Objectif : Identifier, prioriser et remédier aux vulnérabilités suffisamment rapidement pour réduire l'exposition dans le monde réel, couvrant votre code, vos dépendances, votre infrastructure et (si applicable) vos appareils/firmware. L'accent porte sur un flux de travail simple de l'entrée à la correction, des SLA clairs, et un mécanisme de mise à jour qui rend le correctif fiable.

Liste de contrôle :

Preuves minimales :

• Tableau/registre de suivi des vulnérabilités : problème, sévérité, composants/versions affectés, responsable, statut, date cible
• SLA définis (exemple) : triage Critique dans les 48 heures ; cible de remédiation/publication dans X jours (adapté à votre réalité)
• Preuves d'analyse : sorties CI pour l'analyse des dépendances + SAST (et DAST si applicable)
• Correctifs proactifs de dépendances : SBOM ou inventaire des dépendances par publication (au minimum pour les artefacts livrés)
• Enregistrement de publication de correctif : lien depuis le ticket de vulnérabilité vers la/les PR, vers les tests, vers la version de publication, vers la confirmation de déploiement
• Journal des exceptions : les risques acceptés ont un responsable + une date d'expiration/révision et des contrôles compensatoires (le cas échéant)

Porte de publication :

• Les analyses de dépendances et SAST ont été exécutées pour la publication ; les résultats Critique/Élevé sont traités ou font l'objet d'une exception documentée (responsable + expiration)
• Le SBOM (ou inventaire des dépendances) a été généré/mis à jour et stocké pour la publication
• Les vulnérabilités connues affectant les composants livrés sont triées avec sévérité, responsable et date cible
• Le processus de correctif est validé : correction révisée, tests passés, notes de version mises à jour si nécessaire
• Pour les composants exposés sur internet : les atténuations ou correctifs pour les résultats Critique/Élevé sont en place avant la publication
• Les OTA/mises à jour (si applicable) sont validées pour une livraison sécurisée ; retour arrière/rétablissement documenté
• Le risque résiduel accepté est limité dans le temps et suivi jusqu'à la clôture ou la date de révision

Que sont les Machine-Readable Security Manifests ?

La Section 5 du playbook introduit un nouveau concept : le passage d'une conformité statique et documentaire lourde à des attestations de sécurité vérifiables et lisibles par machine.

Une attestation de sécurité lisible par machine est une déclaration numérique en JSON ou YAML affirmant qu'un contrôle de sécurité, un processus ou une propriété spécifique a été satisfait. Contrairement aux rapports PDF statiques, ces attestations peuvent être générées et consommées par des systèmes automatisés, permettant des mises à jour fréquentes et une validation automatisée. Intégrée dans le pipeline de développement, la sécurité devient intrinsèque, et non une case à cocher après le développement.

Quatre propriétés clés

• Démontabilité : capacité proactive à fournir des preuves lisibles par machine que les exigences de sécurité ont été mises en oeuvre, un passage de "affirmer" à "montrer"
• Vérifiabilité : une partie indépendante peut authentifier et valider par programmation l'intégrité des déclarations de sécurité, transparentes, infalsifiables et associées à une racine de confiance reconnue
• Réutilisabilité : utiliser des attestations existantes pour s'appuyer dessus, les intégrer dans le cycle de développement et les inclure dans les portes de qualité agile
• Fiabilité : s'appuyer sur des attestations pour la diligence raisonnable des tiers, simplifiant la confiance dans la chaîne d'approvisionnement

Le modèle en quatre couches

Le playbook illustre un modèle de données hiérarchique où chaque déclaration de sécurité de haut niveau est soutenue par des preuves techniques granulaires :

1. Métadonnées et Attestation (domaine Identité) : identité du produit, versionnement, signature cryptographique du fabricant
2. Couche de Contrôle (domaine Gouvernance) : objectifs de sécurité structurés alignés sur les exigences, principes et réglementations
3. Couche d'Implémentation / Carte Menaces-Atténuations (domaine Opérationnel) : associe les menaces spécifiques aux atténuations implémentées, aux principes de conception, aux paramètres par défaut et aux descriptions lisibles par l'humain
4. Couche d'Évaluation et de Vérification (domaine Preuves) : résultats réussite/échec lisibles par machine issus des portes automatisées, avec liens vers les SBOM

Le document décrit également des couches de contrôle d'accès : un JSON public fournissant des déclarations de haut niveau, et une Surcouche technique restreinte contenant des configurations détaillées d'outils chiffrées et de la télémétrie de tests.

L'écosystème existant

Le playbook situe le MRSM dans le paysage des standards existants :

• OSCAL (NIST) : "Compliance as Code", catalogues de contrôles de sécurité normalisés, plans de sécurité des systèmes, résultats d'évaluation
• CycloneDX CDXA (OWASP/ECMA-424) : format SBOM à l'origine, étendu en standard de transparence complet. Attestations CDXA pour les déclarations de sécurité, VEX pour l'exploitabilité, CBOM pour les actifs cryptographiques
• OpenSSF : Security Insights (faits de sécurité lisibles par machine en YAML), Scorecard (évaluation automatisée des bonnes pratiques)
• OWASP ASVS : Application Security Verification Standard, exigences sous-jacentes. MLSVS étendu à l'IA/ML
• TC54 (Ecma International) : Transparency Exchange API, normalisant la façon dont les SBOM et les attestations sont découverts et partagés

L'exemple travaillé SafeGate-X1

Le document inclut un scénario complet (pages 56 à 61) montrant comment un fabricant fictif de contrôleur matériel implémenterait le MRSM : un modèle de menaces avec 5 menaces (RCE via API web, élévation de privilèges, scan de ports, credential stuffing, falsification de binaire), des contrôles associés aux principes, et un manifeste JSON montrant comment chaque threat_id est associé à un principe, un mitigation_control, un secure_by_default_setting et une verification_gate avec evidence_hash. Il inclut également un tableau de vérification par tiers montrant ce que les auditeurs peuvent vérifier par sondage.

Note : Le MRSM est un concept illustratif, pas un standard proposé. Mais il signale la direction que prend la conformité CRA : des dossiers de preuves PDF statiques vers des artefacts vérifiables et lisibles par machine que votre pipeline CI/CD et vos clients peuvent vérifier automatiquement.

Comment les principes correspondent-ils aux exigences du CRA ?

L'Annexe C du playbook fournit une correspondance complète des 22 principes avec des exigences essentielles spécifiques de l'Annexe I du CRA. C'est le pont d'ingénierie entre les conseils du playbook et vos obligations légales.

L'Annexe I du CRA est divisée en deux parties :

• Partie 1 (ANNEX-1.PT1) : exigences de sécurité des produits, couvrant 14 exigences : évaluation des risques de cybersécurité, valeurs par défaut sécurisées, mises à jour, contrôle d'accès, protection des données, intégrité, minimisation des données, disponibilité, limitation de la surface d'attaque, atténuation des incidents, journalisation et effacement sécurisé des données
• Partie 2 (ANNEX-1.PT2) : exigences de traitement des vulnérabilités, couvrant 8 exigences : SBOM, remédiation rapide, tests, divulgation, VDP coordonnée, entrée des vulnérabilités, distribution sécurisée des correctifs et diffusion rapide

Chaque principe correspond à plusieurs exigences CRA. Voici quelques exemples sélectionnés dans l'Annexe C :

Lien CRA : Le playbook n'est pas une checklist de conformité juridique, mais il fournit le pont d'ingénierie vers l'Annexe I du CRA. Si vous pouvez démontrer le respect de ces 22 principes, vous disposez de preuves substantielles soutenant votre évaluation de conformité CRA.

Que faire ensuite ?

1. Commencer par la Section 2 : Identifier votre phase de cycle de vie actuelle et produire les livrables du Tableau 1. Même une note de Security Context d'une page et un diagramme d'architecture de base vous placent en avance sur la plupart des équipes.

2. Parcourir les 8 activités de gestion des risques (Tableau 2) : La plupart des PME peuvent produire les livrables en 1 à 2 journées de travail concentré. Commencer par le contexte du produit, l'identification des actifs et des préjudices, et vos critères d'acceptation des risques.

3. Faire un modèle de menaces léger (Tableau 3) : Même 2 heures avec votre équipe, en utilisant un tableau blanc et STRIDE, produisent des résultats exploitables. Se concentrer sur les 5 à 10 cas d'abus les plus importants.

4. Sélectionner les 3 à 5 playbooks les plus pertinents pour votre prochaine publication et utiliser les listes de contrôle. Points de départ courants : 4.9 (Codage sécurisé), 4.13 (Gestion des vulnérabilités), 4.2 (Moindre privilège), 4.16 (Accès initial restrictif).

5. Utiliser les critères de porte de publication comme ordre du jour de votre revue de sécurité pré-publication. C'est le chemin le plus rapide pour passer de "pas de processus de revue de sécurité" à "portes de sécurité documentées et reproductibles".

6. Télécharger le playbook ENISA complet : Il s'agit d'un projet v0.4. Soumettre vos retours pendant la période de consultation.

Conseil : Commencer petit. Choisir une publication à venir, appliquer 3 playbooks et utiliser les portes de publication. Vous disposerez de preuves concrètes de pratiques Secure by Design sur lesquelles vous pourrez construire.

Sources officielles

• Playbook ENISA Security by Design and Default v0.4 (PDF)

Guides connexes

• CRA Product Classification Guide
• SBOM Requirements Under the CRA
• CRA Technical File (Annex VII) Guide
• CRA Vulnerability Reporting: The 24-Hour Rule
• CRA Conformity Assessment Decision Guide

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des conseils de conformité spécifiques, consultez un professionnel juridique qualifié.