« Secure by Design » : ce que le nouveau guide de l’ENISA signifie pour les petites équipes

La plupart des petites équipes chargées du développement logiciel et matériel s'accordent à dire que la sécurité est importante. Mais s'accorder sur ce point n'est pas le plus difficile. Le plus difficile, c'est de savoir exactement quoi mettre en place. Et lorsqu'on doit le faire avec un budget quasi inexistant et sans personnel dédié à la sécurité, le fossé entre les intentions et la mise en œuvre ne tarde pas à se creuser.

C’est précisément cette lacune que l’ENISA vient d’essayer de combler. En juillet 2026, l’Agence de l’Union européenne pour la cybersécurité a publié le Guide pratique « Secure by Design and Default ». Il s’agit d’un guide pratique spécialement conçu pour les petites et moyennes entreprises. Ce document ne se contente pas de répéter le conseil habituel consistant à « anticiper la sécurité en amont ». Il décompose plutôt le concept de « sécurité dès la conception » en 22 guides d’application concrets. Chacun d’entre eux comprend une liste de contrôle, une liste des preuves minimales requises et un critère de validation que votre équipe peut copier directement dans un modèle de pull request.

Cet article passe en revue le contenu du guide. Il explique pourquoi ces recommandations ont été mises en place et comment une équipe réduite peut commencer à les appliquer sans avoir à créer au préalable un service dédié à la sécurité.

Ce guide s'adresse à un public spécifique : les développeurs de logiciels, les chefs de produit techniques, les responsables de la sécurité dans les PME et les architectes système travaillant avec des ressources limitées. Si cela correspond à votre équipe, sachez que ce guide a été rédigé spécialement pour vous, et non pour un service de sécurité d'une entreprise du classement Fortune 500.

Pourquoi « Secure by Design » avait besoin de son propre guide pratique

Le concept de « sécurité dès la conception » semble simple : intégrer la protection dès le départ plutôt que de l'ajouter a posteriori. Cependant, les idées simples ne se traduisent pas toujours par des actions simples.

L'ENISA met en évidence un schéma récurrent. Les PME du secteur manufacturier sont confrontées à des contraintes budgétaires, à un savoir-faire limité en matière de sécurité et à une pression constante de la part de l'entreprise en termes de délais. Par conséquent, des principes qui semblent évidents lors d'une conférence restent souvent lettre morte dans le code source.

La loi sur la cyber-résilience (CRA) renforce encore davantage les exigences. Les produits comportant des éléments numériques vendus dans l’Union européenne doivent désormais présenter un niveau adéquat de cybersécurité. Ils doivent également être livrés avec des configurations par défaut sécurisées et prendre en charge des mises à jour de sécurité en temps opportun. Ainsi, la « sécurité dès la conception » n’est plus seulement une bonne pratique. Pour de nombreux fabricants, elle devient une condition d’accès au marché.

Ce guide ne fournit pas de conseils juridiques. Il offre en revanche aux équipes d’ingénieurs quelque chose de bien plus utile au quotidien : une méthode reproductible pour transposer les principes liés à la CRA dans le cadre du travail quotidien des sprints.

Deux idées, quatre catégories

L'ENISA articule ses recommandations autour de deux concepts liés, mais distincts.

Le concept de « Secure by design » porte sur la manière dont un système est conçu. Il s'agit d'intégrer dès le premier jour la modélisation des menaces, les modèles d'architecture sécurisée et la gestion des vulnérabilités dans le processus de développement. C'est très différent de les mettre en place a posteriori, après le lancement.

La sécurité par défaut désigne les mesures mises en place dès la première mise en marche du produit par l'utilisateur. Un produit « sécurisé par défaut » est livré avec la configuration la plus protectrice raisonnablement possible. Les utilisateurs ne devraient pas avoir besoin de connaissances spécialisées pour bénéficier d'une sécurité optimale dès la sortie de l'emballage.

Dans le cadre de l’approche « Secure by Design », l’ENISA regroupe les principes en deux catégories : les fondements architecturaux et l’intégrité opérationnelle. Les fondements architecturaux concernent la structure du système. L’intégrité opérationnelle, quant à elle, porte sur la manière dont celui-ci est géré et entretenu après sa mise en service. Dans le cadre de l’approche « Secure by Default », les principes se divisent en deux catégories : le renforcement par défaut et la protection guidée. Le renforcement par défaut décrit l’état du système à sa sortie d’usine. La protection guidée, quant à elle, décrit la manière dont le système aide les utilisateurs à rester en sécurité au fil du temps.

Ces quatre catégories regroupent à elles seules l'ensemble des 22 guides pratiques. Elles couvrent des thèmes allant des limites de confiance et du principe du privilège minimal jusqu'à la reprise sécurisée et au transfert de propriété.

Dans les coulisses d'un guide pratique : comment fonctionnent réellement les listes de contrôle

Chacun des 22 guides pratiques suit la même structure en cinq parties. C'est notamment cette cohérence qui rend ce guide si pratique pour les petites équipes.

On commence par le principe lui-même, formulé en une seule phrase. Vient ensuite l'objectif : quel type de défaillance ce principe est censé prévenir. Puis, une liste de contrôle énumère les actions ayant le plus grand impact. Celles-ci sont conçues pour être mises en œuvre par des équipes « lean », et non par de grandes structures dédiées à la sécurité.

Ensuite, une section intitulée « Preuves minimales » répertorie l'ensemble minimal d'éléments prouvant que la liste de contrôle a bien été mise en œuvre. Enfin, une « porte de validation » propose des critères de réussite ou d'échec que vous pouvez directement intégrer dans un pipeline d'intégration continue (CI) ou dans une revue de mise en production.

Prenons par exemple la réduction de la surface d’attaque. La liste de contrôle demande aux équipes de répertorier toutes les interfaces exposées et d’appliquer des règles réseau basées sur le principe du « refus par défaut ». Elle leur demande également de supprimer les outils de développement et de diagnostic des versions de production, et de réduire au minimum les données collectées dès le départ. Le processus de validation de mise en production vérifie ensuite, avant chaque mise en production, qu’aucun nouveau port ou point de terminaison d’administration n’a échappé au contrôle.

Ce format est important car il permet de transformer l'expression « renforcer la sécurité » en un élément que le développeur peut réellement cocher lors de la révision d'une pull request.

Ces principes couvrent l'ensemble du cycle de vie du produit

Ces 22 guides couvrent toutes les étapes du cycle de vie d'un produit, et pas seulement la phase de développement.

Les limites de confiance et la modélisation des menaces sont prioritaires. Les équipes doivent savoir ce qu'elles protègent avant de pouvoir le faire. Viennent ensuite le principe du « privilège minimal », une architecture d'identité robuste et la défense en profondeur. Ensemble, ces éléments constituent la colonne vertébrale architecturale du système.

Les principes d'intégrité opérationnelle prennent alors le relais. Cela inclut les pratiques de codage sécurisé, la journalisation et la surveillance, la réponse aux incidents, ainsi que la gestion des vulnérabilités et des correctifs. Les contrôles de la chaîne d'approvisionnement viennent compléter l'aspect conception. Ils couvrent tous les aspects, depuis les artefacts de compilation signés jusqu'aux nomenclatures logicielles (SBOM).

En ce qui concerne les paramètres par défaut, le guide d’implémentation traite du contenu livré dans la boîte. Cela implique une réduction au minimum des services par défaut, l’absence d’identifiants d’administration partagés, une communication chiffrée dès la première connexion et des clés secrètes uniques pour chaque appareil. Des principes de protection guidés aident ensuite les utilisateurs à garantir leur sécurité après la configuration. Cela passe par des étapes d’intégration obligatoires, des mises à jour automatiques et des avertissements clairs chaque fois qu’un utilisateur désactive une mesure de protection.

Il convient notamment de noter que l'ENISA considère ces étapes du cycle de vie comme itératives plutôt que séquentielles. Une vulnérabilité détectée en production devrait entraîner un retour aux étapes antérieures de modélisation des menaces et d'évaluation des risques, et non pas se limiter à un simple correctif rapide et à un haussement d'épaules.

Modélisation des menaces sans surcoût

De nombreuses petites équipes évitent la modélisation des menaces, car celle-ci leur semble être un exercice de plusieurs semaines réservé aux services de sécurité des grandes entreprises. Dans la pratique, l’ENISA réfute directement cette idée reçue.

Le guide recommande le cadre en quatre questions d’Adam Shostack comme point de départ simple. Sur quoi travaillons-nous ? Quels sont les risques ? Que comptons-nous faire pour y remédier ? Avons-nous fait du bon travail ? Les équipes peuvent répondre à ces questions à l’aide d’un simple schéma et d’une brève liste des principales menaces. Un tableau simple mettant en correspondance chaque menace avec les mesures d’atténuation prévues vient compléter l’exercice.

L'objectif n'est pas de produire une documentation exhaustive. Il s'agit plutôt d'un modèle minimal viable, rapide à élaborer et facile à mettre à jour. Il est essentiel qu'il reste étroitement lié aux décisions de conception réelles. Un modèle de menaces que personne ne met à jour après la première version ne vaut même pas la peine d'être élaboré.

Le prouver, et pas seulement l'affirmer

L'une des sections les plus tournées vers l'avenir de ce guide traite de l'attestation exploitable par machine. Plutôt que de s'appuyer sur un rapport PDF statique que personne ne lit après l'audit, l'ENISA explique comment les déclarations de sécurité peuvent être exprimées sous forme de données structurées et lisibles par machine.

Par exemple, une attestation signée peut indiquer qu’un produit prend en charge le protocole TLS 1.3 avec un chiffrement AES-256. Cette affirmation est alors associée à des preuves concrètes, telles qu’une analyse de configuration, un résultat de test ou un journal de compilation. Des systèmes automatisés peuvent vérifier cette affirmation sans avoir à attendre l’intervention d’un réviseur humain.

Pour une PME, cela revêt une importance particulière, car cela permet de remplacer les audits manuels coûteux par des contrôles automatisés effectués à chaque nouvelle version. Le guide prend toutefois soin de souligner les limites de cette approche. Une attestation à elle seule ne suffit pas à prouver qu’un produit est sécurisé. La vérification et l’évaluation indépendante restent des étapes distinctes et indispensables. Les preuves structurées permettent simplement de rendre ces deux étapes plus rapides et moins coûteuses à mettre en œuvre.

Comment se lancer sans vouloir tout changer d'un seul coup

Vingt-deux guides opérationnels peuvent sembler insurmontables pour une équipe d’ingénieurs composée de cinq personnes. Heureusement, l’ENISA a anticipé cette réaction et propose plutôt une approche progressive de mise en œuvre.

Commencez par définir le contexte. Précisez le périmètre de votre produit, ses utilisateurs et ses principaux risques à l’aide de l’approche simplifiée de modélisation des menaces décrite ci-dessus. À partir de là, établissez une base de référence couvrant les pratiques de codage sécurisé, la journalisation et la surveillance, la gestion des vulnérabilités et les contrôles de la chaîne d’approvisionnement. Si votre produit gère les accès des utilisateurs, ajoutez également à cette base de référence des mesures d’accès initial restrictives et des communications sécurisées par défaut.

Ce n’est qu’une fois ces bases posées que les équipes devront aborder les autres guides opérationnels. Classez-les par ordre de priorité en fonction de vos risques spécifiques et de votre contexte de déploiement, et non selon l’ordre dans lequel ils apparaissent dans le document. L’adoption progressive ne doit toutefois pas servir de prétexte pour reporter les obligations liées à l’évaluation des risques (CRA). Il s’agit simplement d’une séquence réaliste pour les équipes disposant d’un temps et de ressources limités.

À retenir

Le concept de « sécurité dès la conception » a toujours été facile à défendre, mais difficile à mettre en pratique. Le guide de l’ENISA ne résout pas entièrement cette difficulté. Il transforme toutefois un principe vague en 22 listes de contrôle qu’une petite équipe peut réellement passer en revue avant la mise sur le marché. Compte tenu des exigences à venir de la CRA, ce passage de l’aspiration à l’action est exactement ce dont la plupart des fabricants ont besoin à l’heure actuelle.

Si votre équipe n'a pas encore mis en place un modèle de menace simplifié, c'est par là qu'il faut naturellement commencer. Tout le reste du guide s'articule autour de ce point de départ, étape par étape, à chaque phase de lancement.

Pour les équipes qui s'occupent déjà de la conformité aux exigences de la CRA, ce guide mérite également d'être lu en parallèle de l'annexe C du document original. Il établit un lien direct entre chacun des 22 principes et les exigences essentielles spécifiques de la CRA, ce qui peut vous faire gagner un temps précieux lorsque vous constituez un dossier de conformité interne. En d'autres termes, le travail de vérification que vous effectuez à des fins techniques sert également de preuve à des fins réglementaires.

Source : ENISA, Guide pratique « Secure by design and default »