Une checklist SBOM du CRA vous donne-t-elle une page de licences ?

Les équipes produit devraient considérer 2026-2027 comme la fenêtre pour mettre en place l'inventaire des composants, la génération de SBOM, les processus de vulnérabilité et, séparément, les flux de divulgation de licences. Attendre l'évaluation de conformité pour découvrir que vous n'avez aucun dossier de licences tierces révisé crée une double urgence.

Les délais varient selon la classe de produit et les actes d'exécution, et la documentation doit rester à jour pendant toute la période de support. Confirmez toutes les dates auprès d'un juriste ; cette page n'est pas un conseil juridique.

Le périmètre dépend de la classification du produit, pas de la taille de l'entreprise : les produits comportant des éléments numériques mis sur le marché de l'UE entrent dans le périmètre, tandis que les produits déjà couverts par des règles sectorielles spécifiques de l'UE (dispositifs médicaux, véhicules à moteur, aviation civile) et les services cloud purs sans dimension produit en sont généralement exclus. Les logiciels installables, les firmwares, les appareils connectés, et de nombreux modèles de distribution open source commerciale peuvent entrer dans le périmètre lorsqu'ils sont vendus dans l'UE.

Des exclusions pour le SaaS pur existent dans la compréhension courante du marché, mais nécessitent une revue juridique spécifique au produit.

Le CRA exige un SBOM, mais cela ne couvre pas la divulgation de licences. L'Annexe I, Partie II, oblige les fabricants à identifier et documenter les composants, y compris un SBOM dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau, ce qui constitue des données d'identité des composants, pas un texte de licence révisé.

Cette obligation accélère l'adoption du SBOM chez les fournisseurs qui vendent dans l'UE. Les équipes produisent du CycloneDX ou du SPDX depuis leur CI, souvent pour la première fois, et remettent les fichiers à la sécurité ou à la conformité. Le SBOM satisfait la documentation des composants du CRA. Il ne produit pas automatiquement la mention, l'attribution ou le texte intégral de la licence pour chaque composant.

La documentation de cybersécurité du CRA couvre l'évaluation des risques, les vulnérabilités, les mises à jour et le développement sécurisé. La sécurité produit, la PSIRT et le juridique portent ce travail. La conformité des licences couvre les obligations de propriété intellectuelle dans les logiciels tiers : mention, attribution, conditions de copyleft. Un flux différent, avec des verrous de révision humaine.

Les confondre crée une fausse confiance. Une équipe peut réussir une revue interne de préparation au CRA avec des SBOM et des SLA de correctifs, tout en échouant à la demande de conformité des licences d'un acheteur, parce que personne n'a révisé le texte des licences.

• SBOM du CRA : identité des composants pour la documentation de sécurité et réglementaire.
• Divulgation de licences : texte intégral et attribution pour le juridique et les achats.
• CRA : signalement des vulnérabilités aux autorités sous des conditions définies.
• Licence : conditions de copyright et de distribution des licences open source.
• Même entrée de lockfile, sorties différentes et responsables différents.

Le CRA attend une documentation mise à jour pendant toute la période de support, à mesure que les vulnérabilités et les composants changent. La même dérive des dépendances rompt les représentations de licences si personne ne révise à nouveau ce qui a été livré.

Les équipes de plusieurs personnes fusionnent en continu des mises à jour de paquets. Sans réimport ni republication à chaque version, votre SBOM du CRA et votre divulgation de licences décrivent tous deux le produit d'hier. La documentation réglementaire et les dossiers destinés aux acheteurs doivent évoluer avec la base de code.

Les grands clients intègrent la posture CRA des fournisseurs dans leurs programmes de chaîne d'approvisionnement, et continuent de coller des sections de licence issues de modèles d'appels d'offres rédigés avant l'existence du CRA. Ils demandent un SBOM, plus une page de licences open source, plus une attestation que la liste est maintenue.

Des équipes achats formées au CRA s'attendront à un accès durable aux artefacts de conformité. Cela ne remplace pas le contenu de la divulgation de licences. Cela relève simplement le niveau d'exigence sur la fraîcheur et l'accessibilité de vos dossiers.

Organisation sécurité : génération de SBOM, gestion des vulnérabilités, signalement des incidents, éléments de conformité CRA, livraison sécurisée des mises à jour.

Conformité / juridique / ops ingénierie : inventaire des licences tierces, révision, verrous de publication, exports de divulgation, réponses aux questionnaires des acheteurs.

Entrée partagée : lockfiles et SBOM depuis la CI. Sorties divergentes : la sécurité utilise le SBOM pour les CVE ; la conformité utilise le même import pour des dossiers de licences révisés.