L'échéance qui arrive avant la norme
Le 11 septembre 2026, l'article 14 du Cyber Resilience Act entre en application. À partir de cette date, tout fabricant qui met sur le marché européen un produit comportant des éléments numériques doit signaler les vulnérabilités activement exploitées et les incidents de sécurité graves : une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification plus complète dans les 72 heures, puis un rapport final dans les 14 jours pour une vulnérabilité ou dans le mois pour un incident.
Dans la plupart des feuilles de route de conformité, le CRA est classé sous 2027. C'est effectivement là que se concentre l'essentiel du règlement : marquage CE, exigences essentielles de sécurité dès la conception, documentation technique et nomenclature logicielle s'appliquent tous à partir du 11 décembre 2027. Mais le signalement en est découplé et arrive en premier. L'obligation vise aussi les produits déjà sur le marché, et pas seulement ceux mis sur le marché après l'échéance.
L'écart entre ces deux dates constitue tout le problème. Vous devez signaler l'exploitation d'un composant dix-huit mois avant d'être tenu de documenter vos composants.
Les dates clés
Le règlement (UE) 2024/2847 est entré en vigueur le 10 décembre 2024. Les obligations de signalement de l'article 14 s'appliquent à partir du 11 septembre 2026. Les autres obligations, dont le SBOM dans la documentation technique, s'appliquent à partir du 11 décembre 2027.
La Commission a publié un guide de mise en œuvre le 27 juillet 2026, et le canal de notification, la Single Reporting Platform exploitée par l'ENISA au titre de l'article 16, doit être disponible le jour même où l'obligation démarre. L'état d'avancement est suivi sur la page de la Commission consacrée au signalement CRA.
Le texte de référence est le règlement (UE) 2024/2847. L'article 14 fixe les obligations de signalement, l'article 16 institue la Single Reporting Platform, et l'annexe I, partie II encadre le traitement des vulnérabilités ainsi que la nomenclature logicielle.
Un cas concret : comment un scanner de sécurité a compromis une passerelle d'IA
En mars 2026, le groupe TeamPCP a compromis LiteLLM, une passerelle d'IA open source largement déployée, qui fait aussi office de proxy. Deux versions malveillantes, 1.82.7 et 1.82.8, sont arrivées sur PyPI. Elles sont restées disponibles une quarantaine de minutes.
Ce qui compte, c'est la manière dont elles y sont parvenues. LiteLLM n'a jamais été visé directement. Sa chaîne de compilation installait le scanner de vulnérabilités Trivy sans l'épingler à une version vérifiée, et le processus de publication de Trivy était lui-même compromis depuis une vingtaine de jours. Le scanner corrompu est entré dans la compilation de LiteLLM et a produit des paquets LiteLLM corrompus. CloudSEK a identifié la même campagne sur un troisième outil, Checkmarx KICS.
Traduit en termes de contrôles : l'outil chargé de trouver les vulnérabilités de la chaîne de compilation était la vulnérabilité de cette chaîne. Il se situait à l'intérieur du périmètre de confiance, s'exécutait avec les habilitations du pipeline et échappait au contrôle appliqué aux dépendances applicatives parce qu'il était classé comme outillage et non comme code.
Un diagramme montrant comment un seul identifiant non révoqué s'est propagé à travers trois outils. TeamPCP compromet le processus de publication du scanner Trivy, point d'entrée resté non détecté une vingtaine de jours. La chaîne d'intégration continue de LiteLLM installe automatiquement la version compromise de Trivy faute d'épinglage, ce qui produit une compilation corrompue. Les paquets LiteLLM 1.82.7 et 1.82.8 arrivent sur PyPI et y restent environ 40 minutes. Ils atteignent environ 434 000 pipelines CI/CD dans plus de 2 500 organisations et collectent clés cloud, jetons de dépôt et clés de services d'IA. Les identifiants collectés restent valides après le retrait des paquets.
La charge malveillante s'exécutait à chaque appel de Python et non au moment de l'import : elle n'avait donc pas besoin qu'une application utilise réellement la bibliothèque. Elle s'exécutait partout où le paquet atterrissait : agents de compilation, images de conteneurs, conteneurs de tâches éphémères, postes de développement, couches en cache. Elle collectait tous les identifiants accessibles à ce processus.
Le jeu de données d'exposition reconstitué par CloudSEK associe au chemin concerné plus de 2 500 organisations et environ 434 000 exécutions de pipelines CI/CD. L'entreprise précise explicitement qu'une correspondance à forte confiance atteste d'une exposition et ne prouve ni la compromission d'une organisation donnée ni l'exfiltration de données. Cette distinction mérite d'être conservée dans une présentation au comité de direction.
Les quarante minutes sont le chiffre trompeur
Une fenêtre de publication courte limite le nombre de compilations ayant récupéré le paquet. Elle ne limite en rien la durée d'utilité des identifiants dérobés. L'alerte FLASH du FBI de juillet 2026 (FLASH-20260702-01) avertit que des acteurs liés à cette campagne exploiteront probablement les identifiants collectés bien après l'intrusion initiale.
La question de confinement porte donc moins sur l'installation de LiteLLM 1.82.7 pendant la fenêtre de quarante minutes que sur les identifiants lisibles par un processus quelconque sur un agent ayant touché ce chemin de dépendances, et sur leur renouvellement effectif. Ce sont deux investigations très différentes, et seule la seconde referme l'exposition.
Pourquoi c'est un sujet CRA et pas seulement un sujet de réponse à incident
Si votre organisation ne fait que consommer du logiciel, la cascade LiteLLM est un incident de sécurité et éventuellement un sujet NIS 2. Si votre organisation livre du logiciel, y compris du logiciel que vous vendez, intégrez, concédez sous licence ou distribuez au sein d'un produit connecté, c'est en outre une obligation de signalement assortie d'un délai.
Au sens du CRA, le fabricant est celui qui développe un produit comportant des éléments numériques et le met sur le marché européen sous son propre nom ou sa propre marque. La taille de l'entreprise n'entre pas en compte. Si vous développez et vendez, vous êtes fabricant, et c'est le rôle qui porte les obligations les plus lourdes. Le SaaS purement navigateur relève généralement de NIS 2 plutôt que du CRA, mais la frontière est plus étroite qu'on ne le croit dès lors que vous livrez un agent, un SDK, une extension, une application mobile ou un micrologiciel.
S'y ajoute une obligation vers l'amont qui épouse exactement la chaîne LiteLLM : le fabricant qui identifie une vulnérabilité dans un composant tiers intégré à son produit doit en informer l'entité qui maintient ce composant. Dans une cascade à trois étages, l'organisation la mieux placée pour repérer la compromission peut se trouver quatre dépendances plus bas.
Ce que chaque régime exige, et dans quel délai
Régime: CRA, art. 14
Régime: NIS 2, art. 23
Régime: DORA, art. 19
Régime: RGPD, art. 33
Le recouvrement est le piège opérationnel. Un seul événement de collecte d'identifiants dans une chaîne de compilation peut déclencher trois de ces quatre régimes en même temps, avec trois délais différents, auprès de trois autorités différentes et selon trois définitions de gravité différentes. Les organisations qui traitent le signalement CRA comme un processus autonome supplémentaire manqueront des délais, tandis que celles qui étendent une procédure existante de qualification et de notification n'en manqueront pas.
Le regard de l'expert : Alexis Hirschhorn
L'échec se situe presque toujours en amont du modèle de notification, dans l'étape de qualification qui l'alimente. Les équipes qui appliquent déjà un processus rigoureux de qualification des incidents selon l'ISO/IEC 27035 absorbent l'article 14 comme un canal de notification supplémentaire, tandis que celles qui n'en ont pas découvrent dès le premier jour que personne ne peut dire, en 24 heures, si une vulnérabilité est activement exploitée. Ce jugement constitue toute l'obligation.
Le délai de 24 heures démarre à la prise de connaissance et non à la fin de l'investigation. Concevez donc le processus pour que ce moment soit défini, tracé et assumé, faute de quoi vous le reconstituerez a posteriori devant une autorité.
Le SBOM dont vous n'avez formellement besoin qu'en 2027, et réellement en septembre
L'annexe I, partie II, point 1 du CRA impose aux fabricants d'identifier et de documenter les composants de leurs produits, notamment en établissant une nomenclature logicielle dans un format lisible par machine couramment utilisé, couvrant au minimum les dépendances de premier niveau. Cette exigence s'applique à partir de décembre 2027.
L'obligation de septembre 2026 la rend de fait nécessaire dès 2026. L'article 14 demande de signaler en 24 heures une vulnérabilité activement exploitée affectant votre produit. Lorsqu'une compromission apparaît dans une bibliothèque située trois niveaux plus bas dans l'arbre de dépendances, la seule façon de répondre dans ce délai à la question de savoir quels produits et quelles versions contiennent ce composant, c'est d'y avoir déjà répondu.
Les dépendances de premier niveau constituent le plancher annoncé, pas une cible sûre. La cascade LiteLLM serait restée invisible dans le SBOM d'un produit en aval limité au premier niveau : Trivy était un outil de compilation et non une dépendance applicative, et LiteLLM lui-même pouvait être transitif. Si votre inventaire s'arrête aux dépendances directes, il ne répond pas à la question posée par le règlement.
SBOM
Inventaire lisible par machine des composants d'un logiciel, avec les informations de version et de fournisseur. CycloneDX et SPDX sont les deux formats courants. La directive technique BSI TR-03183-2 précise une interprétation technique détaillée des attentes du CRA et constitue à ce jour la référence la plus concrète.
Quatre lacunes qui font échouer la couverture SBOM en pratique
L'outillage de compilation ne figure pas dans le SBOM. Scanners, linters, formateurs, harnais de tests et automatisation de publication s'exécutent avec les habilitations du pipeline et sont généralement exclus des inventaires de dépendances. C'est précisément la lacune exploitée par TeamPCP.
Le SBOM décrit la livraison, pas l'environnement de compilation. Deux artefacts présentant une nomenclature identique peuvent provenir de chaînes dont l'exposition diffère fortement, parce que la compromission s'est produite dans l'environnement et non dans le code livré.
Les caches et les images de base dérivent par rapport au manifeste. Une dépendance épinglée dans un fichier de verrouillage n'équivaut pas à une dépendance épinglée dans la couche réellement exécutée, dès lors qu'interviennent images de base, agents éphémères et caches chauds.
Personne n'assume la fraîcheur. Un SBOM produit à la livraison et jamais régénéré répond à une question portant sur le passé. Le délai de 24 heures pose une question portant sur le présent.
Champ d'application : trois questions qui tranchent
Mettez-vous sur le marché européen un produit comportant des éléments numériques sous votre propre nom ou votre propre marque ? Si oui, vous êtes fabricant et l'article 14 s'applique à vous à partir du 11 septembre 2026, y compris pour les produits déjà vendus.
Le produit est-il encore sur le marché européen à cette date ou après ? Les produits existants relèvent de l'obligation de signalement. Les exigences essentielles, plus lourdes, ne les atteignent qu'en cas de modification substantielle, à partir de décembre 2027.
Est-il réellement hors champ ? Le SaaS purement navigateur est généralement hors CRA, et l'open source non commercial est exclu, même si le règlement crée un rôle allégé de gestionnaire de logiciels open source plutôt qu'une exclusion générale, et même si la fourniture commerciale de composants open source vous y ramène. Être hors du CRA signifie le plus souvent être dans NIS 2 : cette voie mène rarement à une absence totale d'obligation.
Sanctions
Les manquements aux exigences essentielles ou aux obligations du fabricant sont passibles d'amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu.
Le calendrier de l'article 14, de bout en bout
La notification est adressée au CSIRT désigné comme coordinateur dans l'État membre où se trouve votre établissement principal, et mise à disposition de l'ENISA au même moment. Vous signalez une seule fois, via la Single Reporting Platform, plutôt qu'auprès de chaque autorité séparément.
Notez ce que l'article 14 n'exige pas. Ce n'est pas une obligation de signaler chaque CVE. Sont visées les vulnérabilités activement exploitées et les incidents graves affectant la sécurité du produit. Le CRA lui-même n'impose pas non plus d'informer les clients professionnels, mais relisez vos contrats, car les clients l'imposent de plus en plus par voie contractuelle, avec des délais plus courts que le règlement.
La correction ne fait pas partie de l'obligation de septembre
L'obligation de corriger et de distribuer des mises à jour de sécurité pendant la période de support s'applique à partir du 11 décembre 2027. À partir de septembre 2026 vous devez signaler, et signaler une vulnérabilité que vous ne pouvez pas encore corriger est le cas attendu. Ne retardez pas une notification en attendant un correctif.
Là où le CRA rejoint NIS 2 et la chaîne d'approvisionnement
L'article 21, paragraphe 2, point d) de NIS 2 impose déjà aux entités essentielles et importantes des mesures relatives à la sécurité de la chaîne d'approvisionnement, y compris les aspects liés à la sécurité des relations avec les fournisseurs directs et les prestataires de services. Le CRA aborde le même risque par l'autre bout : il régit ce que ces fournisseurs doivent construire et divulguer.
Pour la plupart des organisations, les deux s'appliquent, dans des rôles distincts. Vous êtes une entité NIS 2 qui pilote ses fournisseurs, et un fabricant CRA piloté par ses clients. Les preuves se recoupent largement : inventaire des composants, processus d'évaluation des fournisseurs, procédure de traitement des vulnérabilités et manuel de notification, à condition d'avoir été conçues une fois et non trois.
C'est là que l'ISO 28000 prend tout son sens. La norme fournit un système de management de la sûreté de la chaîne d'approvisionnement, c'est-à-dire la structure qui manque à la plupart des organisations lorsqu'elles cherchent à traiter les questions de risque fournisseur de manière cohérente entre achats, ingénierie et conformité. L'alternative, un tableur de questionnaires fournisseurs, ne survit pas à une cascade comme LiteLLM, car la partie compromise n'avait jamais été évaluée comme fournisseur par qui que ce soit.
De l'obligation à la capacité, et de la capacité à la certification
Obligation: Qualifier et notifier en 24 h
Obligation: Connaître ses composants
Obligation: Piloter le risque fournisseur et composant
Obligation: Satisfaire NIS 2, art. 21 § 2 d)
Obligation: Porter le programme de bout en bout
Un plan de mise en état en 30 jours
L'objectif réaliste avant le 11 septembre n'est pas la conformité CRA complète. Il s'agit d'être en mesure de produire une notification défendable dans les délais. Le périmètre est bien plus restreint, et il reste atteignable dans le temps disponible.
- Déterminer si vous êtes fabricant au sens du CRA et lister tous les produits encore sur le marché européen qui entrent dans le champ d'application
- Identifier votre CSIRT coordinateur, celui de l'État membre de votre établissement principal, et vous enregistrer sur la Single Reporting Platform
- Définir et documenter la prise de connaissance : qui peut la prononcer, comment elle est tracée, et ce qui déclenche le délai de 24 heures
- Désigner nommément un responsable et un suppléant pour la notification, avec une couverture en dehors des heures ouvrées
- Générer un SBOM pour chaque produit dans le champ, au format CycloneDX ou SPDX, en incluant l'outillage de compilation autant que les dépendances applicatives
- Relier le SBOM à un flux de vulnérabilités afin de répondre en quelques minutes à la question des produits contenant le composant X
- Rédiger la règle de qualification qui distingue une vulnérabilité activement exploitée d'une CVE ordinaire, et l'éprouver sur un cas réel
- Rattacher la notification CRA à vos parcours d'incident NIS 2, DORA et RGPD existants pour qu'un événement ne déclenche pas trois processus non coordonnés
- Mettre en place la voie d'information vers l'amont pour les vulnérabilités trouvées dans des composants tiers
- Conduire un exercice sur table avec la cascade LiteLLM comme scénario, et vous chronométrer jusqu'à la barre des 24 heures
L'exercice sur table est l'étape que les équipes sautent et celle qui révèle les vraies lacunes. Menez-le avec le scénario tel qu'il se présente réellement : un avis public nomme un paquet utilisé par votre chaîne de compilation, vous ignorez encore s'il a atteint la production, et le délai court déjà.
Commencez par l'inventaire des identifiants, pas par celui des dépendances
Pour cette classe d'attaque, l'exposition se définit par ce qu'un processus compromis pouvait lire, et non par ce qu'il importait. Recensez les identifiants accessibles depuis chaque agent de compilation : clés cloud, jetons de registre, jetons de gestion de sources, clés de modèles et d'API, et tout ce qu'un service de métadonnées d'instance permet de récupérer. Cette liste constitue à la fois le périmètre de votre investigation et votre amélioration de contrôle la plus efficace.
Ce qu'il faut en retenir
Malgré le cadrage qu'elle a reçu, la compromission de LiteLLM tient moins d'une histoire d'IA que d'une chaîne de compilation qui faisait confiance à son propre outillage, d'un identifiant non révoqué et d'une chaîne de dépendances que personne n'avait cartographiée. La couche IA n'a fait qu'aggraver les choses, parce que les passerelles d'IA se situent particulièrement près des identifiants des comptes cloud, des fournisseurs de modèles et des bases vectorielles.
Ce qui change le 11 septembre 2026, c'est que le même événement emporte désormais une obligation de notification en 24 heures pour quiconque livre du logiciel dans l'Union. Le règlement vous demande de savoir vite si la cascade vous a atteint et de le dire, plutôt que de l'empêcher.
C'est un problème d'inventaire de composants et de qualification d'incident bien avant d'être un problème réglementaire. Les organisations qui pratiquent déjà les deux comme des disciplines vivront l'article 14 comme un ajout mineur. Les autres disposent d'une trentaine de jours.
