« Mes produits sont-ils sûrs ? » Comment répondre aux clients après une attaque de la chaîne d'approvisionnement

Envoyez une déclaration d'attente en quelques heures, une réponse confirmée dès que vous pouvez la prouver, et un suivi chaque fois que quelque chose change. Dites ce que vous savez, ce que vous vérifiez encore et quand vous ferez le point. Fondez chaque « non affecté » sur ce que vos builds ont réellement installé pendant la fenêtre de l'attaque, et non sur le lockfile d'aujourd'hui.

Cet article porte sur ce qu'il faut dire, quand, et sur quelles preuves. Pour l'enquête elle-même, c'est-à-dire déterminer si un composant vulnérable se trouve dans vos produits et depuis quand, consultez sommes-nous concernés par une CVE ?.

Pourquoi les clients s'adressent à vous, et non au registre de paquets

La semaine qui a suivi une attaque largement médiatisée, nous a raconté le dirigeant d'un petit éditeur de logiciels, ses clients lui envoyaient des SMS : vos produits sont-ils sûrs ? Mes données sont-elles en sécurité ? Ses clients traitent des données sensibles, son équipe ne compte aucun spécialiste de la sécurité, et la question appelait une réponse le jour même.

Les clients ne demandent pas si un paquet a été compromis. Le registre et les chercheurs l'ont déjà dit. Ils demandent si ce que vous leur avez livré le contient, parce que votre produit constitue leur exposition. Leurs propres clients, auditeurs ou régulateurs leur posent la même question. Dans les chaînes d'approvisionnement réglementées, comme les semi-conducteurs, les équipements industriels et la santé, la question relève du contrat, pas de la curiosité.

Ils la reposeront aussi si votre réponse ne peut pas être vérifiée. « Nous ne sommes pas concernés » sans rien derrière est une promesse ; « nous avons vérifié chaque build de release du 24 au 31 mars et aucun n'a installé les versions affectées » est une affirmation sur laquelle ils peuvent s'appuyer.

Quatre attaques récentes et la question que chacune a soulevée

La bonne réponse dépend du fonctionnement de l'attaque : un modèle seul ne suffit donc pas. Pour chacune d'elles, un fait décide de ce que « affecté » signifie pour un fournisseur.

Porte dérobée de xz Utils (CVE-2024-3094), divulguée le 29 mars 2024. Andres Freund a découvert une porte dérobée dans les versions 5.6.0 et 5.6.1 de xz. Les tarballs de release contenaient du code absent du dépôt Git, qui injectait la porte dérobée pendant le build. La NVD et Red Hat lui attribuent tous deux un score de 10.0 en CVSS 3.1. Elle a surtout atteint les distributions rolling et de test : Debian testing, unstable et experimental, Fedora Rawhide et 41, openSUSE Tumbleweed et Kali, tandis que les versions stables n'étaient pas affectées. La question soulevée : une image ou un appareil que nous avons livré contient-il xz 5.6.0 ou 5.6.1, et quelle image de base chaque build a-t-il utilisée ?

Le ver npm Shai-Hulud, par vagues depuis septembre 2025. Les paquets infectés exécutent à l'installation un script qui vole les identifiants npm, GitHub et cloud, puis s'en sert pour publier des versions infectées d'autres paquets. La question soulevée : un job CI a-t-il installé une version infectée, et nos tokens de publication ont-ils été exposés, ce qui ferait de nous un propagateur ? Notre fiche Shai-Hulud liste chaque vague et la manière de vérifier.

LiteLLM sur PyPI, 24 mars 2026. Les versions 1.82.7 et 1.82.8 ont été publiées directement sur PyPI avec du code de vol d'identifiants qui n'a jamais figuré dans le dépôt GitHub du projet. Dans la 1.82.8, un fichier .pth exécutait la charge malveillante au démarrage de n'importe quel interpréteur Python, et pas seulement à l'import de LiteLLM ; il collectait les variables d'environnement, les clés SSH, les identifiants cloud et les secrets Kubernetes. HiddenLayer rattache l'attaque à TeamPCP, qui a aussi visé les outils de Trivy et de Checkmarx ce mois-là. L'avis de LiteLLM lui-même avance deux explications de l'accès initial : il attribue la compromission à la dépendance Trivy de son workflow CI d'analyse de sécurité, et indique que le compte PyPI d'un mainteneur a peut-être été compromis. Même la fenêtre d'exposition varie au sein de ce même avis : environ 40 minutes à un endroit, de 10:39 à 16:00 UTC à un autre. La question soulevée : un build ou un conteneur livré a-t-il inclus ces versions, et quels secrets étaient présents dans cet environnement ?

axios sur npm, 31 mars 2026. Un attaquant a pris le contrôle du compte npm d'un mainteneur et publié axios 1.14.1 et 0.30.4, qui ajoutaient une dépendance, [email protected], dont le script d'installation déposait un cheval de Troie d'accès à distance pour macOS, Windows et Linux. Datadog situe la fenêtre de 00:21 à 03:25 UTC ; selon Snyk, les versions ont été retirées à 03:29 UTC. La question soulevée : un build a-t-il résolu ces versions pendant cette fenêtre ? Un lockfile commité avant la fenêtre répond « non » pour les builds qui l'ont utilisé, et ne dit rien des builds qui ont lancé npm install sans lui.

Attaque	Écosystème	Versions affectées	Fenêtre	Ce que « affecté » signifie pour un fournisseur
xz Utils	Distributions Linux	5.6.0, 5.6.1	Des semaines, jusqu'à la divulgation le 29 mars 2024	Vous l'avez livré, dans une image ou un appareil construit sur une distribution affectée
Shai-Hulud	npm	Des centaines de paquets par vague	Quelques heures à quelques jours par vague	Vous avez fait vos builds avec, et vos tokens ont pu le propager ; vous l'avez peut-être aussi livré
LiteLLM	PyPI	1.82.7, 1.82.8	24 mars 2026, à partir de 10:39 UTC (les sources divergent sur la fin)	Vous avez fait vos builds avec ou l'avez livré, et les secrets de cet environnement ont pu être volés
axios	npm	1.14.1, 0.30.4	31 mars 2026, environ de 00:21 à 03:25 UTC	Vous avez fait vos builds avec pendant la fenêtre ; le cheval de Troie s'est exécuté sur la machine de build

Les mêmes questions se posent pour une vulnérabilité critique qui n'est pas une attaque de la chaîne d'approvisionnement. Quand PHP2Shell a été exploitée en octobre 2026, les clients de chaque produit embarquant PHP ont demandé lesquelles de leurs versions contenaient un PHP affecté. Les étapes ci-dessous s'appliquent telles quelles.

La réponse se fait en trois temps

Étape	Quand	Ce que vous envoyez
Déclaration d'attente	Dans les heures qui suivent l'annonce	Ce que vous savez, ce que vous vérifiez, quand vous ferez le point
Réponse confirmée	Dès que vous pouvez la prouver, généralement le premier jour	« Non affecté » pour des versions nommées, ou « affecté » avec la marche à suivre
Suivi	Quand le correctif est livré, quand vous apprenez du nouveau, quand vous clôturez le dossier	Le même avis, révisé

La première heure : la déclaration d'attente

Une déclaration d'attente (holding statement) est la première déclaration publique que vous faites avant de connaître les faits. Dites quelque chose de vrai, rapidement. Le silence se remplit de suppositions, et un client qui n'a pas de nouvelles de vous suppose que vous n'avez rien remarqué.

• Qui et où. Un expéditeur nommé, sur le canal utilisé par le client, ainsi que votre page sécurité. Un texte commun vaut mieux que des réponses au cas par cas : il reste cohérent, et le service juridique ne le relit qu'une fois.
• Ce qu'elle contient. Que vous avez connaissance de l'attaque, que vous vérifiez vos produits et vos systèmes de build, ce que vous savez à ce stade, quand viendra le prochain point et qui contacter.
• Ce qu'elle ne doit pas contenir. « Nous ne sommes pas concernés » avant d'avoir vérifié, des spéculations sur l'attaquant ou des accusations.

Modèle 1 : déclaration d'attente

Objet : [nom de l'attaque] : notre première déclaration

Madame, Monsieur,

Nous avons connaissance de la compromission signalée de [paquet ou projet] ([versions affectées], publiées le [date]). Notre équipe de sécurité vérifie actuellement chaque release de [produit] ainsi que nos systèmes de build afin de détecter les versions affectées. À ce stade, nous [n'avons trouvé aucune version affectée dans les produits vérifiés / n'avons pas encore achevé la vérification]. Nous vous adresserons un point de situation d'ici le [date et heure, fuseau horaire]. Pour toute question dans l'intervalle, vous pouvez contacter [nom, adresse du contact sécurité]. Nous ne ferons aucune hypothèse sur l'impact avant la fin de la vérification.

Pour un SMS ou une messagerie instantanée, deux phrases suffisent :

Nous avons connaissance de la compromission [nom de l'attaque] et vérifions dès maintenant chaque release de [produit] ainsi que nos builds. Vous recevrez une réponse confirmée de notre part d'ici [heure].

Faites approuver les trois modèles par votre conseil juridique avant d'en avoir besoin.

Le premier jour : confirmer, preuves à l'appui

Deux issues sont possibles, et chacune exige ses propres preuves. Pour une réponse « non affecté », rassemblez :

• le paquet et les versions affectés, d'après l'avis de sécurité ou l'analyse des chercheurs
• vos produits et les versions que les clients exécutent réellement
• pour chacune de ces versions, le build qui l'a produite et l'enregistrement de ce que ce build a installé, et non le lockfile actuel
• chaque build exécuté pendant la fenêtre de l'attaque, y compris les jobs CI qui n'ont jamais produit de release
• pour les vers qui volent des tokens, la présence éventuelle de secrets CI dans les jobs qui auraient pu exécuter le code malveillant

Sommes-nous concernés par une CVE ? explique comment établir chacun de ces éléments.

Chaque affirmation que vous faites doit s'appuyer sur un élément que vous pouvez montrer :

Affirmation	Ce que vous devez pouvoir montrer	Ce qui ne suffit pas
« La version Y du produit X ne contient pas le paquet Z »	La SBOM enregistrée à partir du build de release de la version Y	Un scan du dépôt actuel
« Aucun de nos builds n'a installé les versions compromises »	Les enregistrements d'installation de chaque build pendant la fenêtre	Un lockfile que certains jobs contournent
« Notre pipeline de release n'a pas été compromis »	Les enregistrements réseau et d'utilisation des secrets pour la fenêtre	L'absence d'alertes
« Les clients en version Y sont protégés après la mise à jour »	L'enregistrement du build corrigé, et les identifiants que vous avez renouvelés	Une entrée de changelog

Modèle 2 : non affecté

Objet : [nom de l'attaque] : [produit] n'est pas affecté

Madame, Monsieur,

Nous avons achevé notre vérification concernant la compromission de [paquet] ([versions affectées]). Les versions suivantes de [produit] ne sont pas affectées : [liste des produits et versions vérifiés]. Nous avons vérifié chaque build de release et chaque build CI exécuté entre le [date de début] et le [date de fin]. Cette déclaration repose sur l'enregistrement des composants installés par chaque build de release, et non sur un scan de notre code source actuel. Aucun de ces builds n'a installé les versions affectées. Si vous avez besoin des preuves, nous pouvons vous transmettre la SBOM des versions que vous utilisez, ou une déclaration VEX. Si nous apprenons quoi que ce soit qui modifie cette évaluation, nous vous en informerons. Contact : [nom, adresse du contact sécurité].

Dites « non affecté » pour des versions nommées. N'écrivez jamais « sûr à 100 % ». Si le client demande ensuite la SBOM complète, consultez répondre aux demandes de SBOM des clients.

Modèle 3 : affecté, avec mesures d'atténuation

Objet : [nom de l'attaque] : action requise pour [produit] versions [x à y]

Madame, Monsieur,

Notre vérification concernant la compromission de [paquet] a établi que les versions [x à y] de [produit] sont affectées. Le premier build affecté a été produit le [date] ; la version [z], publiée le [date], ne contient plus [version du paquet].

Ce que cela signifie : [risque en termes simples, par exemple « un composant installé dans ces versions peut envoyer des identifiants du système sur lequel il s'exécute vers un serveur externe »].

Ce que vous devez faire dès maintenant : mettre à jour vers [produit] [z]. Si vous ne pouvez pas effectuer la mise à jour immédiatement, [mesure d'atténuation, par exemple bloquer les connexions sortantes vers les hôtes listés]. Si vous avez utilisé les versions [x à y] de [produit] dans [environnement], renouvelez les [identifiants ou clés] auxquels elles avaient accès.

Ce que nous avons fait : nous avons retiré les versions affectées de nos builds, reconstruit [produit] à partir de dépendances saines, renouvelé les identifiants utilisés par nos systèmes de build et [autres actions]. [Nous avons informé les autorités compétentes lorsque cela était requis.]

Nous vous adresserons le prochain point de situation d'ici le [date], ou plus tôt si la situation évolue. Contact : [nom, adresse du contact sécurité].

Un avis « affecté » peut aussi constituer une obligation légale ; voir la section sur le signalement ci-dessous.

La place de VEX et de CSAF. Une déclaration « non affecté » ou « corrigé » peut être publiée sous forme de VEX, pour que les scanners des clients cessent de signaler le paquet. Les grands clients peuvent aussi attendre un avis de sécurité lisible par machine ; CSAF est le format que la plupart d'entre eux demandent.

Le suivi : clore proprement

Envoyez un suivi quand le correctif est livré, quand votre enquête révèle quelque chose de nouveau, et une note finale à la clôture du dossier. Tenez un seul avis de sécurité par incident et révisez-le plutôt que d'en envoyer un nouveau à chaque fois (mettre à jour, ne pas remplacer). Consignez ce que vous avez dit, à qui et quand : le prochain audit ou le prochain questionnaire de sécurité d'un client vous le demandera.

Que dire quand vous ne savez pas encore

« Nous ne savons pas encore » inspire davantage confiance qu'un « non affecté » qu'il faut ensuite retirer. Des formulations honnêtes, sans alarmer personne :

• « Nous n'avons pas trouvé [paquet] dans [produits vérifiés à ce stade]. Nous vérifions encore [produits ou systèmes de build restants] et vous tiendrons informés d'ici [heure]. »
• « Les versions que vous utilisez ont été construites avant la fenêtre de l'attaque. Nous confirmons qu'aucun build ultérieur ne les a remplacées. »
• « Nous vérifions si l'un de nos systèmes de build a exécuté les versions affectées. Le produit que vous avez installé est une question distincte, et nous répondrons aux deux. »

Les formulations à éviter :

• « Aucun impact, quel qu'il soit »
• « Entièrement sécurisé »
• « Non concerné par aucune attaque de la chaîne d'approvisionnement »
• « Notre scanner n'a rien trouvé »

Quand l'attaque devient une obligation de signalement

Si vous vendez des produits comportant des éléments numériques dans l'UE, le Cyber Resilience Act applique ses obligations de signalement depuis le 11 septembre 2026, jour où l'ENISA a lancé la plateforme unique de signalement. Une vulnérabilité activement exploitée dans votre produit, ou un incident grave ayant un impact sur sa sécurité, déclenche une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification dans les 72 heures et un rapport final, transmis via la plateforme à votre CSIRT coordinateur et à l'ENISA. Le guide du CRA détaille les étapes.

Savoir si une dépendance compromise que vous avez livrée, ou une compromission de votre propre pipeline de build, répond à ces définitions relève de votre jugement et de celui de votre conseil juridique, pas de cet article. Le règlement définit les termes :

• Une « vulnérabilité activement exploitée » est « une vulnérabilité pour laquelle il existe des preuves fiables qu'un acteur malveillant l'a exploitée dans un système sans l'autorisation du propriétaire du système » (article 3, point 42).
• Un incident est grave lorsqu'« il a ou est susceptible d'avoir une incidence négative sur la capacité d'un produit comportant des éléments numériques à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes », ou lorsqu'« il a conduit ou est susceptible de conduire à l'introduction ou à l'exécution de code malveillant » dans le produit ou dans les systèmes d'un utilisateur (article 14, paragraphe 5).

L'article 14, paragraphe 8, ajoute une obligation envers les utilisateurs : informer les utilisateurs touchés et, le cas échéant, tous les utilisateurs, de la vulnérabilité ou de l'incident et de toute mesure d'atténuation qu'ils peuvent appliquer, « le cas échéant, dans un format structuré, lisible par machine et facilement traitable automatiquement ». Le modèle 3 peut contribuer à remplir cette obligation.

D'autres régimes s'appliquent aussi. Au titre de NIS2, les entités essentielles et importantes notifient les incidents importants à leur CSIRT ou à leur autorité compétente, et de nombreux contrats clients comportent leurs propres clauses de notification, avec leurs propres délais.

Être prêt avant la prochaine attaque

• Un enregistrement de ce que chaque build de release a installé, conservé pendant la période de support du produit (SBOM au moment du build).
• Une liste indiquant quels clients exécutent quelles versions.
• Les trois modèles ci-dessus, approuvés par le service juridique.
• Un expéditeur nommé et un canal pour chaque type de client.
• Une page sécurité et un fichier security.txt où publier les mises à jour (divulgation coordonnée des vulnérabilités).
• Un contrôle des flux sortants sur la CI, pour qu'un paquet compromis ne puisse pas envoyer de secrets vers un hôte dont le build n'a pas besoin (politique de sortie réseau GitHub Actions).

Pour les incidents qui arrivent par centaines plutôt qu'un par un, consultez faire passer un PSIRT à l'échelle.

La place de CRACI

Le tableau des preuves ci-dessus revient sans cesse à une seule chose : un enregistrement de ce que chaque build de release a installé. C'est ce que CRACI conserve. CRACI exécute vos builds GitHub Actions sur ses propres runners et enregistre chaque paquet que chaque job a réellement récupéré, y compris les paquets téléchargés par des scripts d'installation et ceux restaurés depuis des caches. La SBOM de chaque build passé est conservée : la question « un build a-t-il installé axios 1.14.1 pendant la fenêtre ? » trouve sa réponse dans l'historique des builds, avec la période pendant laquelle vous étiez concerné, aussi loin que remonte votre conservation.

Les releases malveillantes connues qui ont une CVE publiée, comme la porte dérobée de xz, sont signalées comme n'importe quelle autre vulnérabilité, et un policy gate peut bloquer les builds qui les contiennent. CRACI ne détecte pas un nouveau paquet malveillant d'après son comportement ou sa réputation.

La politique de sortie réseau de CRACI bloque les connexions vers les hôtes dont un build n'a pas besoin, ce qui limite ce qu'un script d'installation malveillant peut envoyer, même lors d'une attaque encore jamais vue. Quand un client demande les preuves, vous pouvez exporter la SBOM des versions qu'il utilise au format CycloneDX ou SPDX et la lui envoyer. CRACI prend en charge VEX.

Répondez à « étions-nous concernés ? » à partir de votre historique de builds, ou découvrez plus en détail le fonctionnement des attaques de la chaîne d'approvisionnement.

Quand CRACI n'est pas la réponse

• Vous avez besoin d'aide pour la communication elle-même. Les relations presse et le conseil juridique sont un autre métier.
• Le logiciel affecté n'a pas été construit sur CRACI. CRACI enregistre les builds GitHub Actions qui s'exécutent sur ses runners ; les autres systèmes CI sont sur la roadmap.
• La question porte sur le produit d'un fournisseur que vous n'avez pas construit. Des SBOM fournisseurs peuvent être ajoutées à CRACI, mais la réponse ne vaut que ce que vaut la SBOM du fournisseur.
• Vous devez repérer un tout nouveau paquet malveillant avant qu'un avis de sécurité n'existe. CRACI signale les releases malveillantes connues dès qu'un avis avec une CVE est publié ; il ne détecte pas les logiciels malveillants d'après leur comportement ou leur réputation (répondre aux vulnérabilités zero-day).

Questions fréquentes

Que dire aux clients quand une attaque de la chaîne d'approvisionnement fait l'actualité ?

Envoyez une déclaration d'attente en quelques heures : vous avez connaissance de l'attaque, vous vérifiez vos produits et vos builds, ce que vous savez à ce stade, et quand vous ferez le point. Faites-la suivre d'une réponse confirmée pour des versions de produits nommées dès que vous pouvez l'appuyer sur les enregistrements de build, puis d'un suivi chaque fois que quelque chose change.

Que doit contenir une déclaration d'attente ?

Ce qui s'est passé en une phrase, le fait que vous vérifiez vos produits et vos systèmes de build, ce que vous avez trouvé à ce stade, l'heure du prochain point et un contact. Elle ne doit pas affirmer « non affecté » avant que vous ayez vérifié, ni spéculer sur l'attaquant, ni accuser qui que ce soit.

Comment dire « nous ne sommes pas concernés » sans trop promettre ?

Nommez les produits et versions que vous avez vérifiés, la période des builds vérifiés et les preuves utilisées, comme l'enregistrement des composants installés par chaque build de release. Dites « non affecté » pour ces versions, proposez la SBOM ou une déclaration VEX, et engagez-vous à faire le point si quelque chose change. Évitez « sûr à 100 % » ou « entièrement sécurisé ».

Que doit contenir un avis « nous étions affectés » adressé aux clients ?

Les produits et versions affectés, depuis quand et jusqu'à quelle version corrigée, le risque en termes simples, ce que le client doit faire maintenant (mettre à jour, renouveler les identifiants, bloquer des hôtes), ce que vous avez déjà fait, quand viendra le prochain point et qui contacter.

Quelles preuves doivent étayer une déclaration « non affecté » ?

Pour chaque version qu'exécutent les clients, l'enregistrement de ce qu'a installé le build qui l'a produite, et non le lockfile d'aujourd'hui. Ajoutez les enregistrements de chaque build exécuté pendant la fenêtre de l'attaque et, pour les attaques qui volent des identifiants, la présence éventuelle de secrets dans les jobs qui auraient pu exécuter le code malveillant.

Dois-je signaler une attaque de la chaîne d'approvisionnement au titre du Cyber Resilience Act ?

Peut-être. Depuis le 11 septembre 2026, les fabricants de produits comportant des éléments numériques vendus dans l'UE doivent signaler les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité du produit : une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final. Savoir si une attaque donnée est concernée relève de votre jugement et de celui de votre conseil juridique.

Dans quel délai faut-il répondre aux clients ?

En quelques heures avec une déclaration d'attente, même si elle indique seulement que vous vérifiez et quand vous ferez le point. La réponse confirmée suit dès que vous pouvez la prouver. Un « nous vérifions » rapide et honnête fait plus pour la confiance qu'un « non affecté » tardif.