Sécurité dès la conception CRA : passer au travail produit

La « sécurité dès la conception » n’est pas un document de politique à signer. Pour un produit comportant des éléments numériques, elle doit être visible dans les décisions de conception, la réduction de la surface d’attaque, les paramètres sécurisés par défaut, le traitement des mises à jour, les tests et la gestion des vulnérabilités tout au long du cycle de vie.

Le modèle pratique est simple : risque → exigence → décision de conception → action → test → résultat → preuve → revue.

Traduisez les exigences essentielles en travail sur le produit

L’annexe I du CRA contient les exigences essentielles de cybersécurité. Dans le travail produit concret, les équipes doivent notamment traiter les domaines suivants :

conception du produit avec un niveau de cybersécurité adapté aux risques ;
protection contre les accès non autorisés ;
confidentialité, intégrité et disponibilité des données et des fonctions ;
réduction de la surface d’attaque ;
mécanismes limitant l’impact d’un incident ;
enregistrement et surveillance des activités pertinentes liées à la sécurité ;
suppression sécurisée des données et des paramètres ;
distribution sécurisée des mises à jour ;
tests et revues de sécurité réguliers ;
divulgation coordonnée des vulnérabilités.

Une liste de contrôle est un point de départ. Elle ne prouve pas l’exécution.

Exemple : « protéger contre les accès non autorisés »

Une fiche insuffisante indique :

« Le système dispose d’une authentification. »

Une fiche opérationnelle peut montrer :

Risque : la compromission d’un compte administrateur pourrait modifier une configuration critique pour la sécurité.
Décision : les rôles privilégiés nécessitent un mécanisme défini d’authentification et de contrôle des sessions.
Responsable : une personne ou une équipe identifiée.
Mise en œuvre : lien vers la modification d’ingénierie.
Test : scénario vérifiant le comportement requis.
Résultat : PASS/FAIL avec la version du produit et la date.
Preuve : rapport, journal, capture d’écran ou fichier de test.
Revue : nouvelle évaluation après modification de l’authentification ou du profil de risque.

Des mois plus tard, l’organisation peut montrer ce qu’elle avait prévu, mais aussi ce qui a réellement été vérifié.

Sécurité par défaut

La configuration par défaut est importante parce que de nombreux utilisateurs ne modifient pas les paramètres de sécurité après le déploiement. Les exigences du CRA couvrent notamment la configuration sécurisée, les mises à jour et les mécanismes de protection.

Pour chaque fonction ayant un effet significatif sur la sécurité, demandez-vous :

quelle configuration est fournie par défaut à un nouvel utilisateur ;
pourquoi ce réglage convient à une utilisation normale ;
quelles protections peuvent être affaiblies ou désactivées ;
si les modifications risquées sont compréhensibles pour l’utilisateur ;
si le produit peut revenir à un état sécurisé ;
quel test vérifie le comportement après installation et mise à jour.

Intégrez la sécurité au processus de publication, pas à la documentation après la publication

La revue d’une version doit vérifier au minimum :

si le modèle de menace ou le profil de risque a changé ;
si de nouvelles dépendances ont été introduites ;
si les tests de sécurité couvrent la modification ;
si les décisions relatives aux vulnérabilités connues sont documentées ;
si les informations de sécurité destinées aux utilisateurs restent exactes ;
si les hypothèses et dépendances de la période d’assistance restent réalistes ;
si les preuves sont rattachées à la bonne version du produit.

Si ces questions sont posées pour la première fois pendant un audit, l’organisation possède un processus documentaire plutôt qu’une sécurité dès la conception.

ENISA : des actions reproductibles plutôt que des slogans

L’ENISA a publié son guide « Secure by Design and Default Playbook » destiné aux PME le 30 juillet 2026. Ce document vise à traduire les principes en actions reproductibles dans les processus existants d’ingénierie, de gestion produit et de publication. Le même principe s’applique au CRA : utilisez le véritable processus de livraison de l’équipe, puis explicitez les responsabilités et les preuves.

Comment Pulsar soutient un processus fondé sur les preuves

Les risques, contrôles, tâches, documents, preuves, audits et rapports dans Pulsar permettent de relier une décision de conception à sa mise en œuvre, à sa vérification et à sa revue.

L’IA dans Pulsar doit rester une aide à la préparation de brouillons. Elle ne doit pas approuver de manière autonome une évaluation des risques, une exception de sécurité ou une décision de conformité du produit.

Découvrez Pulsar GRC dans un processus allant de l’exigence à la preuve

Guides associés

Commencer par les usages et les limites du produit

Une revue de conception doit décrire les utilisateurs, les fonctions, les données et les situations dans lesquelles le produit est prévu pour fonctionner. Conservez également les usages prévisibles qui peuvent créer un risque. Un produit installé dans un environnement contrôlé ne présente pas nécessairement les mêmes contraintes qu’un composant accessible à des utilisateurs externes. L’équipe doit expliquer le contexte retenu au lieu de copier une liste de mesures sans examiner leur pertinence.

Décrivez les frontières importantes : interfaces, comptes, composants externes et services à distance. Pour chacune, indiquez ce qui est accepté et ce qui doit être refusé. Cette description apporte une base aux choix de conception et aux essais. Elle ne constitue pas une preuve de sécurité complète. Les risques et les critères applicables doivent être examinés par les personnes compétentes, en relation avec la version du produit et les sources pertinentes.

Transformer une décision de conception en critère d’essai

Une mesure doit avoir un effet observable. Si l’équipe décide de limiter une opération à un rôle autorisé, le plan d’essai doit vérifier ce qui se passe avec un rôle autorisé, un rôle différent et une session qui n’est plus valable. Les cas précis dépendent du produit. Le dossier conserve le résultat attendu, le résultat observé et la version examinée. Une description « contrôle d’accès présent » ne suffit pas à expliquer le comportement réel.

Examinez aussi les chemins moins visibles : récupération de compte, outils d’administration, interfaces secondaires ou traitements de secours. Une mesure efficace sur le parcours principal peut être contournée ailleurs. Lorsque le périmètre des essais est limité, indiquez les éléments non examinés. L’approbation doit pouvoir tenir compte de ces limites plutôt que transformer un résultat positif sur quelques cas en assurance générale sur le produit.

Examiner les paramètres livrés aux utilisateurs

Les paramètres par défaut influencent directement la situation de sécurité à la première utilisation. Vérifiez la configuration effectivement fournie, les fonctions actives et les actions nécessaires pour un usage correct. Les valeurs utilisées dans l’environnement de développement ne décrivent pas toujours la configuration distribuée. Gardez les éléments qui permettent de reproduire l’examen, notamment la version, le mode d’installation et les conditions de démarrage.

Si un utilisateur peut modifier un paramètre important, décrivez les conséquences et les informations qu’il doit recevoir. La documentation ne remplace pas la mesure de conception, mais elle aide à comprendre les limites d’utilisation. Vérifiez sa cohérence avec le comportement du produit. Une instruction disant qu’une option est désactivée alors qu’elle reste active dans la configuration livrée crée une fausse représentation pour l’utilisateur et pour le dossier technique.

Exemple proposé : un compte d’administration

Dans un scénario fictif, le produit comprend une opération réservée à l’administration. L’équipe identifie les effets d’un usage non autorisé, choisit les mesures et prépare les essais. Elle vérifie le parcours d’authentification, les droits de l’opération et l’histoire des décisions pertinentes. Une réussite de connexion ne démontre pas à elle seule que les actions autorisées sont correctement limitées. Les contrôles doivent répondre au risque effectivement décrit.

La revue examine ensuite la manière dont un administrateur quitte son rôle ou dont un accès doit être révoqué. Le produit doit être testé selon sa conception et les critères choisis. Si une dépendance externe intervient, conservez les faits nécessaires à l’évaluation de cette relation. Cet exemple est une méthode de travail, pas une déclaration que toutes ces fonctions sont présentes dans Pulsar ou une garantie que leur existence établit la conformité au CRA.

Garder les résultats défavorables dans le dossier

Un essai qui échoue constitue une information importante sur la conception. Reliez-le au risque et au travail de correction, puis conservez le nouvel essai réalisé après modification. Supprimer le premier résultat pour ne montrer que le dernier détruit l’histoire utile de la décision. Le réviseur doit pouvoir comprendre ce qui a été changé et pourquoi les nouvelles preuves permettent d’accepter le résultat.

Une équipe peut aussi décider de reporter une modification. Cette décision doit préciser la limite, la mesure provisoire, la personne responsable et le point de réexamen. Le statut d’une tâche ne suffit pas à expliquer l’acceptation d’un risque. Si le report affecte la mise à disposition du produit ou l’information aux utilisateurs, le responsable de ces décisions doit disposer du même contexte et des pièces pertinentes.

Relier les changements de composants à la conception

Une mise à jour de dépendance peut modifier des fonctions, des paramètres ou des garanties sur lesquels la conception reposait. Identifiez les éléments à réexaminer et les essais nécessaires. La présence d’une nouvelle version ne signifie pas automatiquement que la situation est meilleure dans tous les contextes. Le dossier doit conserver le motif du changement, la source de l’information et les résultats observés dans votre produit.

Les informations relatives aux vulnérabilités doivent suivre une logique semblable. L’équipe examine leur pertinence, le périmètre affecté et les mesures possibles. Les critères de signalement CRA constituent une analyse distincte avec ses responsabilités. La conception, le traitement technique et la décision réglementaire peuvent être reliés au même événement, tout en gardant les étapes et les compétences nécessaires à chaque conclusion.

Vérifier la capacité de maintenir les mesures

Une mesure dépend parfois d’un service, d’un composant ou d’une procédure de mise à jour. Examinez ce qui est nécessaire pour la conserver pendant la période d’assistance prévue. Si un fournisseur annonce une fin de maintenance, le responsable produit doit apprécier ses effets sur les mesures retenues. Une conception acceptable à la première publication peut devenir insuffisante si ses dépendances ne sont plus maintenues.

Conservez la relation entre cette revue, la période d’assistance et la documentation destinée aux utilisateurs. Les décisions doivent être prises sur des informations identifiées, avec les incertitudes encore ouvertes. Ce guide propose un parcours de preuve et de revue ; il ne fixe pas une liste universelle de mesures suffisantes pour tout produit. Les exigences du CRA et les autres sources applicables restent les bases de l’évaluation.

Utiliser un outil pour le suivi, pas pour l’acceptation automatique

Pulsar GRC peut relier les exigences, risques, contrôles, tâches et preuves de revue. Les outils techniques réalisent les essais et produisent les résultats. Il ne faut pas supposer une collecte automatique depuis tous les systèmes de développement ou le cloud. Définissez comment les pièces sont ajoutées et qui vérifie leur contexte. La responsabilité de conception et d’acceptation reste dans l’organisation.

Pour un premier essai, choisissez une mesure et une version fictive ou un périmètre non confidentiel. Le parcours doit montrer le critère, l’essai, l’écart éventuel et la décision humaine. L’IA peut préparer un brouillon de description à examiner ; elle ne valide pas une mesure par sa seule présence dans un texte. Un dossier que le réviseur comprend vaut davantage qu’un grand nombre de contrôles déclarés sans preuves.

Sources

État documentaire du guide : 2 octobre 2026. Vérifiez les instructions opérationnelles actuelles avant toute notification.

Pulsar GRC — accès, isolation des données et export (polonais)