Vulnérabilités des composants IoT : fournisseurs, décisions et correctifs

Le règlement sur la cyberrésilience impose aux fabricants de recenser et de documenter les vulnérabilités et les composants des produits comportant des éléments numériques, notamment en établissant une nomenclature logicielle (SBOM) dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau.

Générer le fichier ne termine pas le travail. Une SBOM devient utile sur le plan opérationnel lorsque l’équipe peut passer d’un composant à une version réelle du produit, à une vulnérabilité, à une décision sur l’impact, à une correction et aux preuves de vérification.

Ce que le CRA prévoit pour les SBOM

La partie II de l’annexe I impose aux fabricants de recenser et de documenter les vulnérabilités et les composants du produit, notamment en établissant une SBOM.

L’annexe VII relie la SBOM à la documentation technique des processus de traitement des vulnérabilités. Une autorité de surveillance du marché peut également demander la SBOM pertinente lorsqu’elle est nécessaire pour vérifier la conformité aux exigences essentielles de cybersécurité.

Une distinction importante : le règlement ne prévoit pas que chaque fabricant doit publier la SBOM complète à l’intention de tous les utilisateurs. L’annexe II demande d’indiquer où une SBOM est accessible si le fabricant décide de la mettre à disposition de l’utilisateur.

Le format de fichier n’est que la première décision

CycloneDX et SPDX sont des formats SBOM largement utilisés. Le choix d’un format ne résout pas la gestion du cycle de vie.

Pour chaque fichier SBOM, consignez au minimum :

• le produit ;
• la version publiée ;
• la date et l’heure de génération ;
• l’outil et le processus de génération ;
• le périmètre de l’analyse ;
• la version du format ;
• l’emplacement de stockage ;
• l’identifiant ou l’empreinte du fichier ;
• l’état de validation.

Sans lien avec une version publiée, il peut devenir impossible de déterminer ultérieurement si un composant a réellement été livré à un client.

Le processus qui crée de la valeur

composant → version du composant → version du produit → vulnérabilité → évaluation de l’impact → décision → action → correction → test → preuve → communication

Exemple :

1. l’outil identifie la bibliothèque X dans la version 4.8.1 ;
2. une vulnérabilité est divulguée pour certaines versions de X ;
3. l’équipe confirme si le code concerné est présent et pertinent dans le produit ;
4. une évaluation de l’impact et une décision de priorité sont consignées ;
5. la correction est liée à une modification précise et à une version du produit ;
6. un test vérifie le résultat ;
7. les preuves de vérification sont jointes au dossier ;
8. si les critères de l’article 14 sont remplis, le processus distinct de signalement CRA commence.

Ni une entrée CVE ni la SBOM elle-même ne décide à la place de l’équipe de l’impact sur le produit.

SBOM et fournisseurs

Un composant peut provenir d’un projet à code source ouvert, d’un fournisseur commercial ou d’une autre équipe interne. Un processus maîtrisé relie donc la dépendance aux éléments suivants :

• fournisseur ou source ;
• état de maintenance ;
• source d’information sur les vulnérabilités ;
• personne responsable de sa mise à jour ;
• solution de remplacement si le composant n’est plus pris en charge.

Ces éléments comptent aussi pour les décisions sur la période d’assistance. Le CRA permet aux fabricants de tenir compte des périodes d’assistance de composants tiers intégrés qui assurent des fonctions essentielles.

Ne transformez pas la GRC en un outil d’analyse supplémentaire

Pulsar n’a pas vocation à concurrencer les outils d’analyse de la composition logicielle, les outils d’analyse des dépendances et les générateurs de SBOM. Ces outils identifient et décrivent les composants.

La GRC apporte de la valeur lorsqu’elle utilise leurs résultats pour soutenir des décisions maîtrisées :

• associer un fichier au produit et à la version publiée ;
• relier le risque et l’action ;
• désigner un responsable et une échéance ;
• conserver la décision ;
• joindre les preuves de correction et de test ;
• fournir l’historique lors d’une revue.

Utilisez Pulsar pour organiser les risques, actions, fournisseurs, documents, preuves et rapports liés au traitement des composants. Convenez de la prise en charge des formats CycloneDX/SPDX dans le périmètre de votre service avant de prévoir un import de SBOM.

Vérifiez votre processus actuel

• Pouvez-vous identifier la SBOM d’une version précise ?
• Sa génération est-elle reproductible ?
• Chaque composant critique possède-t-il un responsable ou une source ?
• Une vulnérabilité peut-elle être reliée à une version du produit concernée ?
• Une décision d’acceptation du risque possède-t-elle une personne chargée de l’approbation et une date de revue ?
• La correction dispose-t-elle de preuves de vérification ?
• Une règle claire permet-elle de passer du traitement des vulnérabilités à l’évaluation du besoin de signalement CRA ?

Découvrez Pulsar GRC dans un processus de gestion des preuves

Guides associés

• Signalement CRA à 24/72 heures
• Documentation technique CRA
• Périodes d’assistance CRA

Vérifier que la nomenclature décrit la version publiée

Une SBOM utile doit correspondre à un produit et à une version identifiés. Avant de l’examiner, retrouvez la publication concernée et la méthode qui a produit le fichier. Une nomenclature créée sur une branche de développement peut différer du produit effectivement distribué. Conservez la date de production, le responsable et les limites connues de l’outil. Cette traçabilité permet de savoir ce que le fichier couvre, sans lui attribuer une précision qu’il ne possède pas.

Comparez la nomenclature aux éléments que l’équipe sait présents dans le produit. Certaines dépendances peuvent être ajoutées pendant l’assemblage, fournies par un composant externe ou absentes d’une analyse limitée au code source. Documentez les écarts et leur traitement. Une validation du format montre que le fichier respecte une structure ; elle ne prouve pas que l’inventaire est complet. Les deux examens doivent rester distincts dans la décision d’acceptation.

Rendre les composants identifiables

Des noms ambigus rendent la recherche de vulnérabilités difficile. Vérifiez les identifiants, les versions et les informations qui permettent de distinguer des composants portant un nom semblable. Conservez la provenance disponible et les relations utiles entre dépendances. Si une information manque, indiquez le responsable de sa recherche. Remplacer une version inconnue par la version la plus récente trouvée en ligne créerait une fausse précision dans le dossier du produit.

Pour un composant modifié par votre équipe, gardez la relation avec sa source et les changements pertinents. Une vulnérabilité publiée pour une version d’origine peut demander une appréciation particulière dans un composant adapté. Cette appréciation doit reposer sur l’analyse technique du produit. Le registre ne doit pas conclure automatiquement à l’absence de risque parce que le nom ou le numéro de version a été modifié par le fabricant.

Exemple de traitement d’un avis de vulnérabilité

Prenez un scénario fictif : un avis de sécurité concerne une bibliothèque mentionnée dans la SBOM. Le responsable retrouve les versions distribuées qui l’utilisent, puis examine si les conditions d’exploitation existent dans le produit. La simple correspondance entre un identifiant et un avis est un point de départ. Elle ne démontre ni une exploitation active ni le besoin immédiat de signalement CRA. Conservez les faits techniques qui justifient la décision.

Si la vulnérabilité est pertinente, reliez l’analyse au risque, à la correction et aux essais nécessaires. Si elle ne l’est pas dans une version, indiquez pourquoi : fonction absente, condition non présente ou autre conclusion démontrée. Une déclaration générique « non concerné » laisse la prochaine équipe sans base de revue. Les informations nouvelles, une nouvelle configuration ou un changement de composant peuvent modifier la conclusion et doivent conduire à un nouvel examen.

Définir les preuves d’une correction

La clôture demande plus qu’une nouvelle SBOM. Vérifiez la modification, les résultats d’essais et la version dans laquelle la mesure a été publiée. Le composant peut être remplacé, corrigé ou traité par une mesure différente ; le dossier doit expliquer l’effet attendu et les limites. Enregistrez les versions antérieures encore prises en charge et ce qui leur arrive. Une correction réalisée pour une branche ne couvre pas automatiquement toutes les versions distribuées.

Conservez aussi les informations destinées aux utilisateurs lorsqu’elles sont nécessaires au traitement. Une mesure qui exige une action locale ne produit pas son effet si le client ne sait pas comment l’appliquer. Coordonnez la documentation, le support et les responsables de sécurité. La preuve de publication et la preuve de communication répondent à des questions différentes ; elles peuvent être liées au même événement sans être confondues.

Garder une SBOM à chaque étape pertinente

Définissez à quel moment l’équipe produit la nomenclature et qui l’examine. Selon votre méthode, la revue peut être rattachée à une version publiée, à un changement important ou à une mise à jour d’une dépendance. Le rythme doit correspondre au produit et aux obligations applicables. Cet article ne fixe pas une fréquence universelle. Il propose de rendre la décision explicite, puis de vérifier que le fichier associé au produit reste accessible.

Une ancienne nomenclature ne doit pas être écrasée sans conserver son contexte. Elle peut être nécessaire pour comprendre un produit encore utilisé ou une décision prise avant une correction. Gardez l’historique selon la politique de conservation applicable et les droits de l’organisation. L’augmentation du nombre de fichiers n’est pas le but ; la capacité à examiner une version précise, avec les pièces qui la décrivent, constitue le résultat recherché.

Partager selon un périmètre approuvé

Une SBOM peut révéler des informations sur la conception du produit. Avant de la transmettre, définissez le destinataire, le besoin et les éléments à communiquer selon les règles applicables. Un client peut demander des informations pour son évaluation fournisseur ; un autre acteur peut intervenir dans une procédure différente. La disponibilité d’un export dans un outil interne ne décide pas de ce qui doit être rendu public ou transmis intégralement.

Conservez une copie de la sélection communiquée, sa version, la date et l’approbation. Si le fichier est modifié pour un partage, expliquez cette modification et gardez la relation avec l’original. Le destinataire doit pouvoir comprendre le périmètre de l’information. Une nomenclature tronquée présentée comme complète crée un risque de décision erronée pour l’organisation qui la reçoit comme pour celle qui l’a produite.

Utiliser Pulsar pour l’histoire de la décision

Les outils de construction et d’analyse produisent les données techniques. Pulsar GRC peut conserver les documents, risques, tâches et preuves qui expliquent leur examen. Il ne faut pas supposer qu’il génère automatiquement une SBOM ou analyse toutes les dépendances de votre cloud. Convenez du processus d’import ou de référencement et du périmètre effectivement disponible. L’organisation garde la responsabilité de la qualité de l’inventaire et de la conclusion technique.

Pour un premier essai, utilisez une nomenclature fictive et un avis simulé. Demandez aux participants de retrouver le produit, la version, le responsable de l’analyse et la décision de traitement. La préparation du dossier doit montrer les incertitudes et les étapes ouvertes. Une liste de composants sans cette histoire reste difficile à exploiter, même lorsqu’elle est longue et conforme au format choisi.

Une vulnérabilité de composant IoT synthétique

Prenons l’exemple d’un capteur industriel fictif doté d’un composant micrologiciel connecté au réseau et fourni par une autre société. Le fabricant reçoit un avis de vulnérabilité nommant ce composant. L’exercice commence par cet avis et se termine par une décision et des preuves examinées. Cela ne suppose pas que tous les produits contenant le composant sont concernés, ni qu’une correspondance SBOM prouve l’exploitation.

Identifiez la version du produit et du micrologiciel distribuée aux utilisateurs. Comparez l’identité et la version du composant avec la notification, puis enregistrez les conditions dans lesquelles la fonction vulnérable peut être atteinte. Incluez les versions prises en charge qui nécessitent une révision. Un nom de composant en amont peut être insuffisant lorsque le fournisseur a rétroporté un correctif ou modifié une version. Demandez les informations nécessaires pour résoudre cette question spécifique.

Créez un enregistrement de fournisseur ou liez le fournisseur existant dans le flux de travail disponible de Pulsar. Enregistrez un risque et une action pour évaluer l’avis. Nommez le propriétaire du produit et la personne qui examine la conclusion technique. Joignez une notice synthétique et une description de la version du produit. Gardez leur statut fictif visible afin que l’exercice ne puisse pas être confondu avec un rapport de vulnérabilité opérationnelle.

Pour l’exemple, supposons que l’examen technique trouve une configuration affectée. Préparer une action pour obtenir et évaluer le composant corrigé. Définir le test qui établira le résultat dans les conditions réelles de fonctionnement du capteur. Un fournisseur indiquant « corrigé » est une entrée pertinente, mais le fabricant a toujours besoin de preuves que la version et la configuration qu’il livre répondent aux critères d’acceptation.

Après le test, joignez le résultat fictif et enregistrez la décision révisée. Liez-le à la version concernée et à tout travail de déploiement restant. Un composant corrigé dans un environnement de test ne démontre pas que tous les appareils déployés ont été mis à jour. Gardez les tâches de publication, de distribution et de communication client distinctes là où elles font partie du processus réel.

Examinez les obligations de déclaration séparément par rapport aux faits établis et aux conditions applicables de l’CRA. Depuis le 11 septembre 2026, les obligations de déclaration de l’article 14 s’appliquent aux vulnérabilités activement exploitées et aux incidents graves spécifiés pour les produits concernés. Ne signalez pas chaque correspondance de composant comme une vulnérabilité exploitée et ne traitez pas cet exercice comme un dépôt officiel.

L’essai évalue si Pulsar permet à votre équipe de localiser le contexte du produit, la question du fournisseur, le propriétaire, l’action et les preuves à l’appui. Il ne transforme pas Pulsar en un générateur SBOM, un scanner de vulnérabilités, un programme de mise à jour du micrologiciel ou un service de reporting automatique. Commencez par ce cas synthétique pendant l’essai de 14 jours, examinez son mode de paiement requis et ses conditions d’annulation, et décidez si l’enregistrement prend en charge votre propre flux de travail de produit.

Révisez les conditions et démarrez l’essai de 14 jours

CRA pour SaaS : portée, actions détenues et preuves

KSC/NIS2 polonais pour les fournisseurs informatiques : évaluation et registre d’actions

API et MCP dans GRC : définir l’accès avant de connecter les systèmes