État de la plateforme et mises à jour
Aucune exposition détectée chez Buckler
Notre examen n’a révélé aucune exposition aux incidents du secteur énumérés ci-dessous.
Portée : les 13 incidents couverts par ce rapport. Conclusions proposées en attente de validation technique; elles ne constituent ni un état de disponibilité en temps réel ni une garantie de risque nul.
repérés lors de cet examen
Les incidents d’octobre dans la chaîne d’approvisionnement logicielle
Une vague d’attaques contre la chaîne d’approvisionnement logicielle a frappé le secteur ce mois-ci. Cette page explique les événements, la façon dont Buckler a vérifié sa propre exposition et les résultats de cet examen.
Ce qui s’est passé dans le secteur
Treize incidents distincts se sont produits sur une courte période. Comme ils ne relèvent pas tous du même problème, nous les avons regroupés selon les actions des attaquants. La plupart concernaient des paquets logiciels compromis. Les autres allaient d’un outil en ligne de commande doté d’une porte dérobée à une autorité de certification dont les clés avaient été compromises.
Comment nous avons effectué les vérifications
La liste soulève deux questions distinctes, auxquelles nous avons répondu séparément.
La première question est de savoir si nous importons des paquets compromis. Pour y répondre, nous avons examiné tous les fichiers de dépendances de chaque base de code Buckler, y compris les fichiers de verrouillage Python et les manifestes Node, en recherchant chacun des paquets mentionnés dans la liste.
La deuxième question est de savoir si nous utilisons un fournisseur ou un outil compromis. Pour y répondre, nous avons comparé les fournisseurs de la liste aux services sur lesquels repose réellement notre plateforme. Un paquet que nous n’importons jamais ne peut pas nous affecter, et un fournisseur auquel nous n’avons jamais souscrit ne peut pas divulguer nos données.
Notre exposition, incident par incident
Voici chaque incident de la liste et son incidence éventuelle sur Buckler. Chaque ligne est verte, car nous avons confirmé qu’aucun de ces incidents ne nous touche.
| Incident | Nature de l’incident | Situation chez Buckler |
|---|---|---|
| LiteLLM | Version malveillante publiée sur l’index de paquets Python | Absent de notre code |
| Tensorlake | Paquet npm infecté | Absent de notre code |
| SubQuery | Paquet npm contenant une porte dérobée | Absent de notre code |
| GhostAction | Processus malveillants ajoutés aux pipelines de compilation | Absent de nos pipelines |
| Node.js | Faille de l’environnement d’exécution, désormais corrigée | Absent de la production |
| PHP | Faille critique d’exécution de code à distance | Nous n’utilisons pas PHP |
| Rank Math PRO | Logiciel malveillant dans un module WordPress | Nous n’utilisons pas WordPress |
| TeamUpdraft | Données clients compromises (sauvegarde WordPress) | Nous n’utilisons pas WordPress |
| Zeabur | Hébergeur compromis | Pas d’hébergement chez ce fournisseur |
| eMudhra | Clés d’une autorité de certification compromises | Nous ne l’utilisons pas |
| OpenCode | Clés API exposées | Nous ne l’utilisons pas |
| ConnectWise | Identités de sauvegarde infonuagique compromises | Nous ne l’utilisons pas |
| OVHcloud CLI | Binaires officiels contenant une porte dérobée | Nous ne l’utilisons pas |
Un nom sur la liste ne signifie pas nécessairement une exposition
Un élément mérite une lecture attentive. La présence d’un fournisseur dans une liste de compromissions ne signifie pas qu’une entreprise qui utilise ses services est exposée. L’incident OVHcloud ne concernait qu’un seul composant : les attaquants ont remplacé les binaires de son outil en ligne de commande. La compromission ne touchait ni la console Web ni une connexion SSH ordinaire.
Nous n’utilisons pas cet outil en ligne de commande; cet incident ne nous touche donc pas. Nous avons vérifié ce point directement plutôt que de le présumer, ce qui explique le statut indiqué dans le tableau.
Nos pratiques courantes
Ces incidents n’ont pas nécessité de mobilisation improvisée, car les contrôles ci-dessous sont déjà appliqués au quotidien. Les attaques contre la chaîne d’approvisionnement constituent un risque connu, que nous prenons en compte dès la conception.
Versions de dépendances verrouillées
Chaque service consigne la version exacte de chaque paquet qu’il installe. Une nouvelle version ne peut pas s’introduire à notre insu sans que nous l’ayons choisie.
Analyses automatisées
À chaque modification, nos pipelines de compilation analysent les dépendances et recherchent les secrets exposés, afin de détecter rapidement les paquets dont le caractère malveillant est connu.
Identifiants distincts
Chaque système possède ses propres clés. L’exposition d’un identifiant ne donne pas accès au reste de la plateforme.
Dépendances examinées
Nous n’adoptons pas de nouveau paquet sans raison et sans l’avoir examiné. Une liste plus courte est une liste plus sûre.