Depuis le 11 septembre 2026, le Cyber Resilience Act impose aux fabricants de produits numériques une obligation de notification des vulnérabilités. Cette échéance a concentré l'attention des équipes sécurité sur la procédure de déclaration. Mais une question reste dans l'angle mort : que se passe-t-il quand votre produit s'appuie, comme la quasi-totalité des logiciels modernes, sur des composants open source ?
Le rapport Open Source Security and Risk Analysis 2024 de Synopsys révèle que 96 % des bases de code commerciales contiennent des composants open source. Pour ces organisations, le CRA ne se résume pas à une obligation de notification : il redéfinit la chaîne de responsabilités et impose un inventaire que beaucoup n'ont pas encore constitué.
L'open source "pur" est exclu, mais votre produit ne l'est pas
Le CRA exclut de son périmètre les logiciels libres développés hors de toute activité commerciale. Un développeur qui publie un projet sur une forge publique pour la communauté, sans contrepartie économique, n'est pas soumis aux obligations du règlement.
La frontière s'arrête là. Dès qu'un composant open source est intégré dans un produit commercial, le fabricant de ce produit assume l'entière responsabilité CRA. La licence du composant (MIT, Apache, GPL) est sans effet sur cette attribution. Vous distribuez le produit, vous en répondez.
C'est la règle du "fabricant" au sens du règlement : toute entité qui place un produit contenant des éléments numériques sur le marché européen, même si elle n'a écrit qu'une fraction du code qui le compose.
Le statut d'open-source software steward
Le CRA crée un statut intermédiaire : l'"open-source software steward". Ce terme désigne les structures (généralement des fondations ou des consortiums) qui assurent le maintien et la pérennité d'un projet open source utilisé dans des environnements commerciaux, sans en être les fabricants directs.
Ce statut ouvre un régime allégé. Les stewards ne sont pas soumis aux exigences essentielles de sécurité ni aux procédures d'évaluation de conformité complètes. En revanche, ils doivent coopérer avec les autorités de surveillance et mettre en place une politique de gestion des vulnérabilités.
Pour votre organisation, ce statut change peu de chose si vous êtes intégrateur. Il vous importe de savoir si un projet open source que vous intégrez bénéficie d'un steward actif : cela détermine la maturité de son processus de divulgation des vulnérabilités, donc la vitesse à laquelle vous serez informé d'une faille exploitable dans votre produit.
Ce que le CRA vous impose concrètement
Le règlement impose au fabricant de maintenir une Software Bill of Materials (SBOM) pour toute la durée de vie du produit, au minimum dix ans après sa mise sur le marché. Cette SBOM doit lister chaque composant intégré, y compris les dépendances transitives des bibliothèques open source.
La définition du contenu minimal d'un SBOM conforme inclut : le nom et la version de chaque composant, les identifiants CVE applicables, et les licences. Les formats SPDX et CycloneDX sont les plus utilisés pour l'interopérabilité avec les outils d'analyse automatisée.
À cette exigence de traçabilité s'ajoutent les obligations de notification en vigueur depuis le 11 septembre 2026 : une alerte précoce dans les 24 heures suivant la détection d'une vulnérabilité activement exploitée dans votre produit, un rapport complet dans les 72 heures, et un rapport final sous un mois.
Si cette vulnérabilité provient d'une bibliothèque open source que vous intégrez, le délai de 24 heures court dès que vous en avez connaissance, pas dès que le mainteneur l'a divulguée publiquement. La surveillance active de vos dépendances n'est plus une bonne pratique optionnelle.
Trois points d'action prioritaires
Première action : cartographier vos dépendances open source au-delà des dépendances directes, en descendant dans l'arbre des dépendances transitives. Des outils comme Syft, Trivy ou les capacités SBOM des pipelines CI/CD modernes automatisent cette extraction. Le résultat alimente directement votre SBOM CRA.
Deuxième action : connecter votre chaîne logicielle à des flux de données sur les vulnérabilités. La base EUVD (European Vulnerability Database) publie les CVE pertinents pour le marché européen, relayée vers le CERT-FR en France. Vos équipes doivent tracer la relation entre chaque alerte et les composants de votre inventaire, de manière automatisée.
Troisième action : formaliser votre processus de notification. Si vous détectez une vulnérabilité exploitée dans un composant que vous distribuez, le chemin vers ENISA via votre CSIRT national doit être documenté et testé avant qu'un incident réel ne l'emprunte. Le CRA ne pardonne pas l'improvisation à 24 heures d'une alerte.
L'angle mort : les dépendances de vos prestataires
Un dernier point échappe souvent à l'analyse initiale. Si vous intégrez un composant développé par un prestataire, et que ce composant contient lui-même de l'open source non déclaré, votre SBOM est incomplète et votre conformité CRA est à risque.
La chaîne de responsabilité du CRA pousse la question vers l'amont de votre supply chain logicielle, exactement comme NIS2 et DORA l'ont fait pour la supply chain opérationnelle. Pour les organisations qui ont déjà structuré leur gestion des dépendances dans ce registre, l'extension au périmètre CRA s'appuie sur les mêmes outils. L'article SBOM et inventaire logiciel sous NIS2/DORA : l'obligation que votre DSI n'a pas encore adressée détaille les exigences parallèles qui s'appliquent déjà aujourd'hui.
Vos contrats avec les fournisseurs de composants logiciels doivent désormais inclure des engagements de traçabilité et de divulgation des vulnérabilités. Un fournisseur qui ne peut pas produire de SBOM pour ce qu'il vous livre représente un risque CRA que vous portez seul.
Ce qu'il faut retenir
Le CRA ne distingue pas le code que vous avez écrit du code que vous avez intégré : il tient le fabricant responsable de l'ensemble du produit qu'il distribue. Pour un produit contenant de l'open source, cela signifie une obligation de traçabilité continue, une surveillance active des vulnérabilités dans vos dépendances, et une capacité de notification opérationnelle dès le moment de la détection.
Ces trois éléments ne sont pas des chantiers de long terme. Avec l'échéance du 11 septembre 2026 passée, ils relèvent de la conformité immédiate. Les équipes qui n'ont pas encore constitué leur SBOM ni formalisé leur processus de notification doivent le faire maintenant.