SBOM et CRA : de CycloneDX/SPDX aux décisions et preuves

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 :

l’outil identifie la bibliothèque X dans la version 4.8.1 ;
une vulnérabilité est divulguée pour certaines versions de X ;
l’équipe confirme si le code concerné est présent et pertinent dans le produit ;
une évaluation de l’impact et une décision de priorité sont consignées ;
la correction est liée à une modification précise et à une version du produit ;
un test vérifie le résultat ;
les preuves de vérification sont jointes au dossier ;
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

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.

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)