Auto-évaluation de maturité

Le jour où vous mettez le produit sur le marché, vous ne connaissez aucune faille exploitable qui le concerne et que vous n'auriez pas corrigée. Ce n'est pas une promesse d'absence totale de vulnérabilité, personne ne peut la tenir : c'est l'interdiction de vendre en sachant. Une faille publiée sur un composant que vous embarquez, une alerte que vous avez reçue, un correctif disponible que vous n'avez pas appliqué : si c'est connu et exploitable dans l'usage prévu, le produit ne doit pas partir en l'état. Cela suppose une veille avant la mise sur le marché, pas seulement après.

Sorti de sa boîte, votre produit doit être sûr sans que personne n'ait rien à régler. Pas de mot de passe identique pour tous les exemplaires, pas de service ouvert dont l'acheteur n'a pas besoin, pas de compte de maintenance laissé actif. Et l'utilisateur doit pouvoir le remettre dans cet état d'origine, ce qui suppose que cet état soit sûr lui aussi. La seule dérogation est le produit sur mesure, avec un accord écrit de l'entreprise cliente, et elle ne couvre pas un produit de catalogue livré avec une configuration relâchée « parce que le client l'a demandé au téléphone ».

Il faut pouvoir réparer votre produit après la vente. C'est une exigence de conception, pas une promesse de maintenance : un produit dont le logiciel ne peut pas être remplacé est non conforme même si vous n'avez jamais eu de faille. Quatre éléments sont demandés ensemble : un mécanisme de mise à jour, des mises à jour automatiques activées par défaut quand cela se justifie, la possibilité de les désactiver facilement, et celle de les différer. Cette dernière n'est pas une faveur : sur un équipement industriel, une mise à jour au mauvais moment arrête une ligne de production.

Il faut savoir qui accède au produit et refuser les autres, et il faut le dire quand quelqu'un a essayé. La seconde moitié de la phrase est celle qu'on oublie : signaler l'accès non autorisé est une exigence en soi, pas un raffinement. Un produit qui refuse correctement mais sans laisser aucune trace ne satisfait pas ce point.

Ce que votre produit stocke et transmet ne doit pas être lisible par qui n'y a pas droit. Le règlement cite le chiffrement en exemple et non comme obligation, mais il exige des « mécanismes de pointe », ce qui écarte les algorithmes obsolètes et les configurations laxistes. Deux états à traiter séparément : au repos, sur le produit et ses supports ; en transit, entre le produit et tout ce à quoi il parle, y compris vos propres serveurs.

Personne ne doit pouvoir modifier à votre insu ce que fait votre produit, ni ce qu'il contient. Le libellé énumère quatre objets et non un seul : les données, les commandes, les programmes et la configuration. C'est le point qui porte le démarrage vérifié et la signature des mises à jour. Et comme pour le contrôle des accès, la dernière exigence est de signaler les corruptions, donc de les détecter.

Votre produit ne doit collecter que ce dont il a besoin pour faire ce qu'il annonce. Le vocabulaire est celui du RGPD et ce n'est pas un hasard, mais la portée est plus large : le texte dit « à caractère personnel ou autres », donc la télémétrie technique et les données d'usage entrent dans le champ. C'est aussi la propriété qui réduit le coût des autres : ce que vous ne collectez pas, vous n'avez ni à le chiffrer, ni à le journaliser, ni à l'effacer.

Votre produit doit continuer à faire l'essentiel, et y revenir après un incident. Deux notions sont à distinguer et le texte les distingue : les fonctions essentielles, sans lesquelles le produit ne remplit plus son office, et les fonctions de base. Le déni de service est cité explicitement, donc un produit qui s'effondre sous un volume de requêtes anormal ne satisfait pas ce point, même si rien n'est corrompu.

Votre produit ne doit pas devenir une nuisance pour les autres. C'est la propriété qui répond aux réseaux d'objets détournés en réseaux d'attaque : un produit qui se laisse enrôler et qui participe à une attaque contre un tiers ne satisfait pas ce point, même si son propriétaire ne s'aperçoit de rien. Deux formes de nuisance sont visées, celle que le produit cause par malveillance subie, et celle qu'il cause par conception, par exemple en interrogeant un service distant bien plus souvent que nécessaire.

Tout ce que votre produit expose est une porte, et chaque porte doit avoir une raison d'être. Le libellé dit « conçus, développés et fabriqués », donc l'exigence porte sur le processus autant que sur le résultat : une interface de test laissée active en sortie d'usine est un défaut de fabrication au sens de ce point. C'est la propriété la plus concrète des treize, et la plus facile à objectiver.

Quand quelque chose passe, il ne faut pas que tout tombe. Cette propriété admet que la compromission arrive et demande d'en limiter la portée : cloisonnement des composants, privilèges réduits, protections d'exécution. C'est la seule des treize qui se place après l'échec des autres, et c'est ce qui la rend difficile à justifier comme non applicable : elle ne suppose aucune vulnérabilité connue, seulement l'hypothèse qu'il en existera une.

Votre produit doit garder trace de ce qui compte pour la sécurité, et l'utilisateur doit pouvoir arrêter cette collecte. La seconde partie surprend souvent et elle est délibérée : le règlement protège aussi l'utilisateur contre une surveillance imposée par son propre équipement. Un produit dont la journalisation ne peut pas être coupée ne satisfait pas ce point, même si ses journaux sont excellents.

L'utilisateur doit pouvoir effacer ce qu'il a mis dans votre produit, et le transférer si c'est prévu. Trois adverbes commandent l'exigence : facilement, en toute sécurité, et de manière permanente. Le dernier est le plus exigeant techniquement : sur une mémoire flash, une suppression logique ne supprime rien, et une remise à l'état d'origine qui ne réécrit pas les données ne satisfait pas ce point. C'est aussi la propriété qui rend possible la revente et la mise au rebut d'un équipement sans fuite.

Vous devez savoir de quoi votre produit est fait. La nomenclature logicielle, ou SBOM, est la liste de ses composants dans un format que d'autres outils savent lire, et elle ne se remplit pas à la main : elle sort de votre chaîne de construction. Le règlement fixe un plancher, les dépendances de niveau supérieur, ce qui veut dire ce que vous incluez directement. Aller plus profond est utile mais n'est pas exigé. Ce point est la fondation des sept autres et de la plupart des treize propriétés : sans inventaire, vous ne pouvez pas savoir qu'une faille publiée vous concerne, donc vous ne pouvez ni la corriger, ni la signaler, ni la publier.

Quand vous découvrez une faille, vous la corrigez, et vite. La seconde moitié de la phrase est celle qui coûte de l'organisation : un correctif de sécurité doit pouvoir être livré seul, sans embarquer les nouveautés en cours de développement. La raison est simple et vos clients la connaissent : une entreprise refuse une mise à jour qui change le comportement de son équipement, donc si vous mélangez, elle n'installe pas le correctif. « Sans retard » n'est pas chiffré dans le texte. Ce qui est évaluable, c'est votre délai constaté et le fait que vous le mesuriez.

Il faut chercher les failles, pas seulement attendre qu'on vous les signale. Deux mots portent l'exigence et ils sont tous les deux évaluables : « régulièrement », donc selon une cadence et non une fois avant la mise sur le marché, et « efficaces », donc adaptés au produit. Un scanner de dépendances passé chaque nuit est un test régulier ; ce n'est pas un test efficace sur un produit matériel dont la surface d'attaque est physique. Le texte ne demande pas un audit externe. Il demande que vos tests trouvent quelque chose.

Quand vous avez corrigé une faille, vous le dites. Pas seulement à celui qui vous l'a signalée : à vos utilisateurs, avec de quoi comprendre ce qui était en jeu et ce qu'ils doivent faire. C'est l'obligation qui surprend le plus les entreprises, parce qu'elle va contre l'instinct de discrétion. Elle a une raison : un utilisateur qui ne sait pas qu'une mise à jour corrige une faille exploitée ne l'installe pas en priorité. Ce que vous publiez est le constat et le remède, pas le mode d'emploi de l'attaque.

Il faut un document qui dit comment vous traitez une faille qu'on vous signale, et ce document doit être vérifiable. C'est une politique publique, pas une procédure interne : un chercheur en sécurité doit pouvoir lire, avant de vous écrire, ce que vous allez faire de son signalement, sous quel délai, et s'il risque quelque chose en vous le signalant. Cette dernière question décide en pratique s'il vous écrit ou s'il publie sans vous prévenir. Nous vendons cette obligation, donc nous en avons une : c'est la page de signalement de resilience-act.fr, avec son périmètre, son délai d'accusé de réception et son engagement de non-poursuite.

Il doit exister une adresse pour vous signaler une faille, et elle doit être facile à trouver. C'est l'obligation la plus simple des huit et la plus souvent manquée, parce qu'elle suppose une adresse qui ne rebondit pas, qui est lue, et qui survit au départ de la personne qui la relevait. Une adresse nominative est un défaut, même si la personne répond vite. Le règlement demande aussi que vous facilitiez le signalement, ce qui va au-delà de publier une adresse : un formulaire qui exige la création d'un compte pour signaler une faille n'est pas une facilitation.

Le chemin par lequel votre correctif arrive doit être sûr. C'est l'obligation qui protège contre le scénario le plus rentable pour un attaquant : ne pas attaquer le produit, mais le canal de mise à jour, et livrer son code à tout le parc en une fois. Trois éléments sont attendus ensemble : l'authenticité du correctif, donc sa signature ; l'intégrité de son transport ; et la certitude qu'il arrive bien, en temps utile. C'est aussi le point où votre propre chaîne de construction entre dans le périmètre : un correctif signé par une clef qui traîne sur un poste de développeur n'est pas authentique, il est signé.

Les correctifs de sécurité sont diffusés vite, et ils ne se paient pas. C'est une obligation économique autant que technique, et elle a des conséquences directes sur votre modèle : vous ne pouvez pas réserver les correctifs de sécurité à un contrat de maintenance, ni les conditionner à une montée de version payante. Un client qui a acheté votre produit a droit aux correctifs pendant toute la période d'assistance, qu'il paie ou non un abonnement de support. Le texte demande aussi un message d'information accompagnant le correctif, donc la diffusion n'est pas seulement la mise à disposition du fichier.