Aller au contenu

CRA : savoir ce qui tourne réellement sur son parc

Le Cyber Resilience Act demande une nomenclature logicielle, des correctifs pendant toute la période de support et un signalement sous 24 heures. Tout cela suppose de savoir ce qui tourne, aujourd’hui, sur les produits déjà livrés.

Actualités · Security · 10 novembre 2026 · 3 min de lecture

Sommaire de l’article
  1. Ce que le CRA demande sur les composants logiciels
  2. Le SBOM de livraison ne suffit pas
  3. Les questions auxquelles il faut savoir répondre
  4. Construire cette capacité
  5. Un exemple concret : PipeLinker
  6. Ce que nous faisons avec vous

Le Cyber Resilience Act s’applique aux produits comportant des éléments numériques mis sur le marché européen. Depuis le 11 septembre 2026, ses obligations de signalement sont en vigueur ; le 11 décembre 2027, l’ensemble des exigences produit s’appliquera.

Plusieurs de ces obligations reposent sur une question simple en apparence : quels logiciels, et dans quelles versions, tournent réellement sur les produits déjà livrés ?

Ce que le CRA demande sur les composants logiciels

Une nomenclature logicielle

L’annexe I du règlement demande aux fabricants d’identifier et de documenter les composants de leurs produits, notamment au moyen d’une nomenclature logicielle (SBOM) dans un format courant et lisible par machine, couvrant au minimum les dépendances de premier niveau.

Des correctifs pendant toute la période de support

Les vulnérabilités doivent être traitées sans retard, et les mises à jour de sécurité mises à disposition gratuitement. La période de support correspond à la durée d’utilisation attendue du produit, avec un minimum de cinq ans sauf si le produit est prévu pour une durée plus courte.

Un signalement rapide

Une vulnérabilité activement exploitée ou un incident grave déclenche une alerte précoce sous 24 heures, puis une notification sous 72 heures et un rapport final. Le délai court à partir de la prise de connaissance par le fabricant.

Délais de l’article 14 du CRA : alerte précoce sous 24 heures, notification complète sous 72 heures, rapport final sous 14 jours ou un mois

Le SBOM de livraison ne suffit pas

Un SBOM produit au moment de la mise sur le marché décrit ce qui a été expédié. Quelques années plus tard, le parc a reçu des mises à jour, des interventions sur site, des cartes remplacées en atelier, parfois des paquets ajoutés par un technicien.

Le jour où un avis de sécurité paraît sur une bibliothèque largement utilisée, la question ne porte pas sur le manifeste d’une version, mais sur le parc tel qu’il est maintenant. Sans réponse fiable, l’alerte précoce se rédige à l’aveugle.

Les questions auxquelles il faut savoir répondre

  • Sommes-nous concernés ? Quels produits embarquent le composant vulnérable, et dans quelle version ?
  • Combien d’appareils, et lesquels ? Chez quels clients, sur quels sites ?
  • Depuis quand ? Quelle version a introduit le composant, et quand a-t-elle été déployée ?
  • Le correctif est-il arrivé ? Sur quels appareils, et comment le prouver ?

Construire cette capacité

Tenir ces réponses à jour repose sur quelques briques :

  1. Un inventaire logiciel continu de chaque appareil, et pas seulement un instantané à la livraison.
  2. Des identifiants normalisés (Package URL, CPE) qui permettent de rapprocher l’inventaire des avis de sécurité, y compris quand une distribution corrige une faille sans changer le numéro de version.
  3. Un format d’échange standard, CycloneDX ou SPDX, lisible par les outils d’analyse de vulnérabilités.
  4. Des mises à jour signées, vérifiées par l’appareil avant installation et déployées progressivement. La formation « Sécuriser la mise à jour des logiciels embarqués » détaille ce point.
  5. La preuve de diffusion : quels appareils ont reçu quel correctif, et quand.

Un exemple concret : PipeLinker

En toute transparence : PipeLinker est un logiciel édité par Lootus Security.

PipeLinker tient cet inventaire pour les parcs Linux, Windows et Android. Les agents remontent en continu les paquets installés sur chaque appareil, avec des identifiants au format Package URL. La nomenclature de chaque appareil s’exporte en CycloneDX, et une recherche porte sur tout le parc à la fois. Les mises à jour sont signées et déployées par étapes.

La page Cyber Resilience Act de PipeLinker détaille ce que l’outil apporte pour chacune de ces obligations.

Ce que nous faisons avec vous

L’inventaire n’est qu’une partie de la conformité. Nous accompagnons les fabricants sur l’ensemble de la démarche : mise en conformité CRA, audit de sécurité du produit, et accompagnement RSSE pour organiser la veille, le traitement des vulnérabilités et les signalements.

Vous préparez vos produits pour le CRA ? Parlons de votre périmètre.

Partager : LinkedIn Facebook E-mail

Un projet à sécuriser ?

Échangeons sur votre périmètre, vos usages et vos priorités de sécurité.

Échanger avec un expert
LOOTUS SECURITY

Expertise cybersécurité IoT, IT, OT et Web.

Découvrir notre équipe