La dernière compilation ne représente pas le portefeuille maintenu
Un éditeur produit une SBOM à chaque livraison, mais ses clients n'installent pas tous la dernière version. Une branche ancienne reste sous maintenance, une autre attend une migration et une troisième est en développement. Lorsqu'une vulnérabilité est publiée, les dépendances du dernier build ne permettent pas de répondre pour tout ce portefeuille. Il faut retrouver les inventaires et les conditions de maintien de chaque version.
Le suivi doit distinguer la correction du code, la disponibilité d'une version corrigée et son déploiement chez le client. À chaque étape correspondent un responsable et une preuve. Le produit, le support et la sécurité peuvent ainsi répondre à partir du même dossier, au lieu de reconstruire séparément leurs analyses.
Vérifier le rôle de l'éditeur et le périmètre du produit
Le Cyber Resilience Act concerne des produits comportant des éléments numériques mis à disposition sur le marché de l'Union, selon ses critères et exclusions. L'analyse porte sur le produit et le rôle de l'éditeur. Pour un SaaS, elle doit notamment examiner le logiciel distribué et les éventuelles solutions de traitement à distance liées au produit. Les logiciels libres relèvent de dispositions spécifiques selon l'activité et le rôle de leurs acteurs.
Au 30 octobre 2026, les obligations de signalement des fabricants s'appliquent depuis le 11 septembre 2026. L'application principale du CRA est prévue au 11 décembre 2027, date à laquelle s'appliqueront aussi les obligations de signalement des gestionnaires de logiciels libres. Un fabricant concerné doit donc déjà organiser les signalements applicables à ses produits, en parallèle de la préparation des autres exigences.
Sources : Commission européenne, lecture du périmètre et des exigences essentielles du CRA, Commission européenne, Cyber Resilience Act et calendrier d'application, Commission européenne, signalements CRA et calendrier des gestionnaires de logiciels libres
Relier inventaire, applicabilité et décision
L'annexe I, partie II, du CRA associe connaissance des composants et gestion des vulnérabilités. Pour qualifier une alerte, rapprochez la version exacte, la provenance, les fonctions utilisées et les conditions décrites par l'éditeur. Un rapprochement de noms ne suffit pas. Si une information manque, attribuez la question à un responsable et gardez la qualification ouverte.
Conservez le produit, la version livrée, l'artefact, la date de l'inventaire et sa source, puis reliez-les à l'analyse et à la décision. La constitution d'une SBOM et sa communication sont deux sujets distincts : le CRA n'impose pas sa publication publique intégrale dans tous les cas. Les informations à communiquer dépendent notamment du destinataire et des dispositions applicables.
Sources : CRA, règlement (UE) 2024/2847, articles 2, 13, 69, 71 et annexe I
Cas fictif : deux branches, deux chemins de correction
Dans cet exemple fictif, Atelier Suite maintient les versions 2.8 et 3.4 de son produit. La première intègre moteur-rendu 1.6 ; la seconde utilise moteur-rendu 2.2. Le signalement DEMO-EDITEUR-01 concerne une fonction présente dans les deux branches, mais le fournisseur propose deux correctifs distincts. La version 4.0, encore en développement, ne règle pas le suivi des versions distribuées.
L'équipe partage l'analyse de la fonction concernée, puis conserve une action par branche. Pour 2.8, le correctif doit être adapté et validé dans l'environnement de maintenance. Pour 3.4, une mise à jour standard est préparée. Le support identifie les clients concernés. La publication des versions corrigées et les confirmations de déploiement restent suivies séparément.
| Niveau | Information à maintenir |
|---|---|
| Produit et version | Branche, état de maintenance et date de support vérifiée |
| Composant | Version, provenance, inventaire et fonction concernée |
| Qualification | Applicabilité, sources, inconnues et réexamen |
| Traitement | Action par branche, validation, distribution et preuve |
Organiser la maintenance pour éviter de reconstruire les réponses
Listez les versions commercialisées et maintenues, puis rattachez une nomenclature à chacune. Prenez un signalement récent : pouvez-vous expliquer quelles versions sont affectées, lesquelles restent à examiner et lesquelles sont corrigées ? Prévoyez les événements qui rouvrent l'analyse : nouvel avis, changement de dépendance, prolongation de support ou évolution des déploiements.
CyberLifeCycle prend en charge le suivi par produit et version : veille sur les composants, qualification, priorités et dossiers de traitement. Vous recevez les alertes et les rapports nécessaires à vos décisions de maintenance. Mesurez le temps de réanalyse, de préparation des réponses clients et les demandes bloquées faute d'information. Le fabricant conserve la conduite du développement sécurisé, des essais, des mises à jour, des notifications et de l'évaluation de conformité.
Sources : Commission européenne, obligations des fabricants avant et après mise sur le marché
Sources consultées
- CRA, règlement (UE) 2024/2847, articles 2, 13, 69, 71 et annexe IConsulté le 30 octobre 2026.
- Commission européenne, Cyber Resilience Act et calendrier d'applicationConsulté le 30 octobre 2026.
- Commission européenne, obligations des fabricants avant et après mise sur le marchéConsulté le 30 octobre 2026.
- Commission européenne, signalements CRA et calendrier des gestionnaires de logiciels libresConsulté le 30 octobre 2026.
- Commission européenne, lecture du périmètre et des exigences essentielles du CRAConsulté le 30 octobre 2026.