Restez vigilants : des attaques ciblées visent des Rustaceans de premier plan

Les équipes de sécurité de Rust ont lancé un avertissement sévère le 17 septembre après qu’au moins une campagne ciblée est passée d’appels vidéo convaincants à la publication de crates malveillantes. Restez vigilants : des attaques ciblées visent des Rustaceans de premier plan n’est pas un simple rappel générique sur le phishing. Les attaquants approchent des membres de projets Rust et des propriétaires de crates populaires, car un seul mainteneur compromis peut exposer des milliers d’environnements de développement en aval.

La campagne présente son premier contact comme une offre d’emploi, une mission de conseil, une discussion d’investissement ou une opportunité contractuelle. Pendant ou après un appel vidéo, la cible rencontre un prétendu problème technique. La solution proposée consiste à installer un codec audio, exécuter une commande ou ouvrir un projet contrôlé par l’attaquant.

Cette approche sociale semble déjà avoir fonctionné. Le 20 août, des attaquants ont publié des versions malveillantes de arrayref, internment et append-only-vec via un compte de mainteneur compromis. Leur code s’exécutait lors de la compilation, transformant une mise à jour de dépendance ordinaire en voie d’accès aux postes de travail des développeurs et aux systèmes d’intégration continue.

Le conflit central ne se résume plus à opposer du code digne de confiance à du code malveillant. Il oppose la confiance personnelle à l’autorité de publication des paquets. Les personnes qui reçoivent ces appels détiennent des droits de publication capables de transformer une compromission privée en incident de chaîne d’approvisionnement logicielle.

Restez vigilants : des attaques ciblées visant des Rustaceans de premier plan deviennent un avertissement pour la chaîne d’approvisionnement

Le projet Rust alerte les mainteneurs, car il estime que les attaquants visent l’accès à la publication, et pas seulement des fichiers individuels ou des mots de passe.

Adam Harvey a publié l’avertissement sur les attaques ciblées pour l’équipe crates.io et le groupe de travail de réponse aux incidents de sécurité de Rust. Ces équipes estiment qu’une campagne en cours cible des membres de rust-lang et des propriétaires de crates populaires.

L’objectif supposé est de compromettre des appareils et des comptes, puis d’utiliser cet accès pour publier des malwares. Cette évaluation relie l’ingénierie sociale privée à un mécanisme de distribution public. Le poste de travail d’un développeur, une session de navigateur, un compte de messagerie ou des identifiants crates.io peuvent devenir le pont entre les deux.

L’approche signalée commence par une opportunité attrayante. Un inconnu propose un emploi, un projet, un rôle de conseil, une discussion sur un investissement ou un contrat. L’invitation est suffisamment personnalisée pour mériter une réponse, et l’appelant peut étayer son récit avec un profil d’apparence professionnelle.

Les attaquants auraient créé des identités d’entreprise plausibles et des présences sur LinkedIn. Ces éléments n’ont pas besoin de résister à une vérification approfondie. Il leur suffit de paraître crédibles durant la courte période entre un message non sollicité et un appel planifié.

L’appel introduit ensuite un obstacle artificiel. L’audio ne fonctionnerait pas, un codec semblerait manquer, ou une commande paraîtrait nécessaire pour rétablir l’accès. Une autre variante place une commande dans le presse-papiers et demande à la cible de la coller dans un terminal.

Ce moment est déterminant, car il présente l’exécution de code comme une opération de dépannage. La cible n’installe pas sciemment un programme inconnu. Elle croit résoudre un problème de communication familier pendant qu’une autre personne attend à l’écran.

L’avertissement de Rust demande aux destinataires d’aborder les sollicitations non sollicitées avec davantage de méfiance et d’utiliser des plateformes auxquelles ils font déjà confiance. Il recommande à la cible de créer elle-même la réunion lorsque c’est possible. Cela élimine au moins un composant contrôlé par l’attaquant de l’interaction.

Il est également demandé aux mainteneurs d’examiner leurs comptes afin de détecter toute activité inattendue et de vérifier que l’authentification multifacteur est activée. Toute personne préoccupée par l’accès à crates.io peut contacter son adresse d’assistance, tandis que les incidents plus généraux peuvent être signalés à l’équipe de sécurité de Rust.

Ces recommandations sont volontairement simples. Le danger de cette campagne ne vient pas d’une obscure vulnérabilité de Rust. Il réside dans une interaction humaine crédible suivie d’une action ordinaire aux conséquences cachées.

L’avertissement n’affirme pas que tous les incidents signalés relèvent d’un même opérateur. Les équipes de Rust précisent explicitement qu’elles ne savent pas encore si les tentatives de juin, la compromission de arrayref et l’activité actuelle constituent une seule campagne. Cette incertitude doit limiter les attributions, mais elle ne réduit pas le risque immédiat.

C’est pourquoi Restez vigilants : des attaques ciblées visent des Rustaceans de premier plan revêt davantage de gravité que ne le suggère sa formulation mesurée. L’avertissement fait suite à une compromission réelle de publication, et non à un modèle de menace hypothétique.

L’incident arrayref a montré ce qu’un seul mainteneur compromis peut ouvrir

L’attaque contre arrayref a transformé le contrôle d’un compte de mainteneur légitime en publications malveillantes dans trois paquets établis.

À 7 h 15 UTC le 20 août, l’équipe de réponse aux incidents de sécurité de Rust a reçu un signalement indiquant que proc-macro1 était malveillant. Les enquêteurs ont confirmé que son script de compilation téléchargeait une charge utile distante.

Un script de compilation est du code que Cargo, le gestionnaire de paquets et système de compilation de Rust, exécute lors de la compilation d’un paquet. Il peut effectuer des tâches de configuration légitimes, mais s’exécute avant le lancement d’une application. C’est donc un endroit attrayant pour dissimuler un malware.

L’équipe a constaté qu’une nouvelle version de arrayref dépendait directement de proc-macro1. Des versions propres récentes avaient également été retirées, ce qui pouvait orienter la résolution des dépendances vers la version malveillante. L’attaquant a reproduit ce schéma avec internment et append-only-vec, deux crates contrôlées par le même compte de mainteneur.

L’avis officiel sur l’incident arrayref a identifié trois publications empoisonnées. arrayref 0.3.10 est resté disponible pendant 86 minutes, internment 0.8.7 pendant 90 minutes et append-only-vec 0.1.9 pendant 107 minutes.

Ces fenêtres paraissent brèves sur un calendrier. Elles sont néanmoins assez longues pour que la résolution automatisée des dépendances, les builds des développeurs, les outils d’édition et les tâches d’intégration continue récupèrent de nouveaux paquets.

L’équipe Rust a supprimé les versions malveillantes et six crates associées. Elle a restauré les versions propres que l’attaquant avait retirées et verrouillé le compte de mainteneur affecté. L’équipe de réponse a déclaré ne pas croire que l’auteur légitime ait agi de manière malveillante.

L’équipe a plutôt estimé que l’ordinateur ou les identifiants de l’auteur avaient probablement été compromis. Cette distinction importe, car elle montre les limites de la réputation. Un paquet familier peut contenir du code contrôlé par un attaquant sans que son mainteneur reconnu ait choisi de l’y ajouter.

Des chercheurs en sécurité ont estimé que arrayref totalisait environ 245 millions de téléchargements cumulés. internment en comptait environ 14,4 millions, tandis que append-only-vec en comptait environ 4,5 millions. Les totaux cumulés ne correspondent pas au nombre d’installations affectées, mais ils montrent pourquoi le choix du compte importe.

Les attaquants n’avaient pas besoin d’introduire un paquet inconnu puis d’attendre son adoption. Ils ont placé une dépendance malveillante derrière des projets que les développeurs acceptaient déjà. Les paquets parents empoisonnés paraissaient par ailleurs familiers.

Ces crates occupaient également des rôles techniques différents. arrayref fournit des macros pour obtenir des références à des tableaux de taille fixe à partir de tranches. internment prend en charge l’internement, qui stocke une copie partagée unique de valeurs répétées. append-only-vec fournit un vecteur concurrent dont les entrées existantes ne sont pas supprimées.

Aucune de ces fonctions ne suggère naturellement le téléchargement d’un exécutable distant. Cette incohérence n’est devenue visible qu’en examinant la nouvelle dépendance et son comportement lors de la compilation.

L’incident a donc changé le contexte de toute fausse opportunité ultérieure. Une prise de contact pour un emploi auprès d’un mainteneur à fort impact ne peut plus être évaluée comme un simple spam personnel. Elle peut constituer le premier mouvement d’une nouvelle attaque contre la chaîne d’approvisionnement Rust.

Une fausse arnaque à l’entretien transforme la courtoisie professionnelle en exécution

Les attaquants exploitent la volonté d’un mainteneur d’évaluer une opportunité, puis organisent l’interaction de façon à ce qu’une coopération normale exécute leur code.

La partie la plus dangereuse de cette campagne se déroule avant que le malware n’atteigne crates.io. Elle commence par des recherches sur la cible. La propriété des paquets, les appartenances à des projets, les apparitions en conférence et les intérêts professionnels sont souvent publics.

Ces informations aident un attaquant à créer une offre pertinente. Un message générique de recruteur peut être ignoré. Une proposition faisant référence au travail du mainteneur peut obtenir une conversation, surtout si elle s’appuie sur un site web d’entreprise et un profil social plausibles.

Un incident de juin documenté par le développeur Rust Matt Mastracci illustre la préparation nécessaire. Un faux représentant d’investissement l’a approché au sujet d’un travail de conseil, a planifié une conversation vidéo, puis a envoyé un exercice technique.

Le dépôt fourni semblait contenir un projet TypeScript ordinaire. Ses instructions demandaient au destinataire d’exécuter des vérifications de types, des tests et des builds. L’analyse de l’attaque déjouée de Mastracci a révélé du code malveillant caché dans un correctif appliqué à TypeScript.

L’exécution des commandes de développement attendues aurait déclenché la charge utile. Le dépôt employait plusieurs couches de dissimulation, dont un composant caché dans une image et un processus détaché. Mastracci a décrit le résultat comme un cheval de Troie d’accès à distance capable d’exécuter des commandes et d’accéder à des fichiers.

Cette affaire n’a pas compromis sa machine parce qu’il a inspecté le projet avant de l’exécuter. Elle démontre toutefois pourquoi les conseils évidents contre le phishing sont insuffisants. L’attaquant n’a pas envoyé une grossière pièce jointe exécutable. L’action nuisible était intégrée au travail que la cible était censée effectuer.

Le nouveau schéma d’appel vidéo concentre cette même pression dans une interaction en direct. Quelqu’un attend pendant que la cible tente de résoudre le problème. Les délais deviennent inconfortables, et une solution suggérée semble plus simple que de mettre fin à la réunion.

La variante du presse-papiers est particulièrement utile aux attaquants. Un site web ou un participant à l’appel peut fournir une commande sans en afficher l’effet complet dans un contexte significatif. La coller dans un shell transfère directement la confiance de la conversation vers le système d’exploitation.

Un prétendu codec fonctionne de la même manière. Les problèmes audio sont suffisamment courants pour que l’explication semble banale. Pourtant, les véritables plateformes de réunion ne devraient pas nécessiter le téléchargement personnalisé d’un contact non sollicité pour faire fonctionner l’audio de base.

L’interprétation la plus sûre n’est pas que toute réunion inconnue est hostile. C’est que l’environnement de réunion ne doit pas recevoir une confiance technique automatique de la part de la personne qui l’a organisé.

Planifier l’appel sur une plateforme connue modifie cet équilibre. Il en va de même pour l’ouverture de dépôts inattendus uniquement dans des environnements jetables et isolés ne contenant aucun identifiant de production. Aucune de ces mesures ne prouve la légitimité de l’appelant, mais toutes deux réduisent la valeur de son scénario.

Cette fausse arnaque à l’entretien vise également davantage que les mots de passe crates.io. Une machine de développeur peut contenir des sessions GitHub, des identifiants cloud, des clés SSH, du matériel de signature, des cookies de navigateur, des jetons de paquets et un accès à des dépôts de code source privés.

Un attaquant peut utiliser n’importe lequel de ces éléments pour étendre la compromission. La crate malveillante finale peut être l’aboutissement visible, tandis que des identifiants organisationnels volés restent non découverts.

C’est là que réside le renversement fondamental de Restez vigilants : des attaques ciblées visent des Rustaceans de premier plan. Les attaquants n’exploitent pas principalement le modèle de mémoire de Rust. Ils exploitent la confiance professionnelle entourant les personnes qui maintiennent l’infrastructure partagée de Rust.

L’exécution au moment de la compilation transforme une petite modification de paquet en une exposition majeure

Les versions malveillantes étaient dangereuses, car Cargo exécutait la dépendance de l’attaquant durant la compilation, avant même que les développeurs en aval n’appellent la moindre fonction de bibliothèque.

Les crates empoisonnées ajoutaient une dépendance nommée proc-macro1. Ce nom ressemblait fortement à proc-macro2, un package légitime très utilisé. Il s’agit de typosquatting : un attaquant choisit un nom conçu pour être confondu avec une dépendance de confiance.

Le package malveillant imitait largement l’apparence du projet légitime. Son comportement nuisible se trouvait dans build.rs, le script de compilation. Cette séparation a permis aux crates parentes de conserver leur code source attendu tout en introduisant la charge utile via une ligne de dépendance.

Selon une analyse technique du package, le script reconstruisait des adresses réseau à partir de fragments encodés et désactivait la validation normale des certificats. Il sélectionnait une charge utile pour Linux, Windows, macOS sur processeur Intel ou macOS sur Apple silicon.

Sur les systèmes de type Unix, le script écrivait un exécutable dans /tmp/rust-setup et le lançait sans attendre sa fin. Sous Windows, il créait un script PowerShell et utilisait un script Visual Basic pour le démarrer dans un processus caché.

La compilation pouvait par ailleurs sembler réussie. C’est essentiel, car un échec visible déclenche souvent une investigation. Un package qui se compile normalement donne aux développeurs moins de raisons d’examiner une dépendance transitive.

Les chercheurs ont également observé que le package copié déclarait des dépendances de compilation supplémentaires, notamment des bibliothèques réseau et de chiffrement. De tels ajouts sont suspects lorsqu’un petit package de macros n’a aucune raison évidente de contacter Internet.

Une analyse distincte a récupéré le malware de seconde étape et identifié des capacités plus étendues. Ses fonctions rapportées comprenaient le profilage de l’hôte, l’inspection des données de navigateur, la persistance, l’exécution de commandes et des méthodes de communication de secours.

L’enquête de Wiz sur le malware a identifié des chevauchements d’infrastructure avec des opérations attribuées ailleurs à des acteurs nord-coréens. L’analyse a établi des liens entre des schémas dans les chemins de commande, les plages d’hébergement et des campagnes associées.

Toutefois, un chevauchement d’infrastructure ne constitue pas une attribution concluante. Des serveurs peuvent être réutilisés, copiés, loués ou délibérément choisis pour semer la confusion chez les enquêteurs. Le projet Rust s’est également abstenu d’affirmer qu’un groupe identifié était responsable de l’ensemble des activités associées.

La conclusion prudente reste néanmoins grave. La chaîne technique était conçue pour survivre à une revue superficielle du code source et s’exécuter lors d’opérations de développement courantes. Compiler un projet dépendant suffisait. Une application n’avait pas besoin d’invoquer arrayref, internment ou append-only-vec.

Cela élargit l’ensemble des victimes potentielles au-delà des déploiements de production. Un développeur qui actualisait un lockfile pouvait être exposé. Il en allait de même pour un exécuteur CI, une tâche automatisée de mise à jour des dépendances ou des outils d’éditeur invoquant Cargo lors de l’analyse d’un projet.

Un lockfile enregistre les versions exactes des dépendances sélectionnées pour une compilation. Lorsqu’il est commité et révisé, il peut révéler si l’une des versions malveillantes a été introduite dans un projet. Pourtant, un lockfile propre aujourd’hui ne prouve pas qu’aucun poste de travail n’a résolu une version affectée durant la période d’exposition.

L’attaque contre la chaîne d’approvisionnement Rust montre également pourquoi les totaux de téléchargements exigent une interprétation prudente. Des centaines de millions de téléchargements historiques ne signifient pas des centaines de millions d’infections. Les versions malveillantes n’ont été disponibles que brièvement, et de nombreux projets restaient verrouillés sur des versions antérieures.

Malgré cela, une version disponible pendant peu de temps peut atteindre des systèmes sensibles, car l’installation des packages est automatisée. La popularité offre à l’attaquant de nombreuses occasions indépendantes durant chaque minute où une version reste disponible.

La voie du code et la voie sociale se renforcent donc mutuellement. Cibler des mainteneurs fournit l’autorité de publication. L’exécution au moment de la compilation transforme cette autorité en exécution immédiate de code dans les environnements en aval.

L’attribution reste incertaine, mais la conclusion défensive ne l’est pas

Les enquêteurs disposent d’indices crédibles d’une campagne coordonnée, mais les preuves disponibles ne démontrent pas que chaque incident Rust relève d’un même opérateur.

L’avertissement de septembre relie trois observations. Des développeurs Rust ont été confrontés à des approches ciblées en juin. Le compte du mainteneur d’arrayref a été compromis en août. De nouvelles sollicitations suspectes se sont poursuivies en septembre.

Les méthodes partagent également une structure reconnaissable. Les attaquants construisent des identités professionnelles, proposent des opportunités attractives, instaurent une interaction en direct et guident la cible vers l’exécution de code. Les victimes visées disposent d’accès susceptibles d’affecter d’autres développeurs.

Cette cohérence étaye l’évaluation d’une campagne. Elle n’établit pas une structure de commandement unique, un commanditaire unique ou une famille de malware unique.

Les équipes Rust reconnaissent explicitement cette lacune. Leur alerte indique qu’elles ne savent pas si les ciblages antérieurs et l’attaque contre arrayref relèvent tous d’une même campagne. Une couverture responsable doit préserver cette réserve.

Le lien avec la RPDC exige une prudence similaire. Des chercheurs en sécurité ont documenté des campagnes nord-coréennes utilisant de faux processus de recrutement contre des développeurs logiciels. Certaines infrastructures et certains schémas techniques du malware arrayref chevaucheraient des opérations précédemment attribuées.

Ces conclusions rendent l’hypothèse pertinente, mais ne la transforment pas en certitude. Un avertissement public ne doit pas être interprété comme une attribution officielle du projet Rust.

Une autre question ouverte concerne la compromission initiale du mainteneur d’arrayref. Le projet estime que l’appareil ou les identifiants du mainteneur ont été compromis, mais son avis public sur l’incident ne fournit pas de chronologie complète des investigations forensiques.

Cela laisse plusieurs possibilités concernant des sessions volées, des identifiants, des données de navigateur ou un accès à un endpoint. La publication de septembre indique que le compte a été compromis par des attaques similaires, sans divulguer chaque étape technique.

Le nombre de victimes effectivement compromises est également inconnu. Les informations publiques confirment la publication de packages malveillants et documentent des approches infructueuses. Elles ne révèlent pas combien de mainteneurs ont installé des logiciels, exécuté des commandes ou signalé en privé des appels suspects.

Le nombre d’infections en aval n’est pas non plus public. Les chercheurs peuvent identifier les versions de packages malveillantes et estimer la prévalence des packages, mais cela diffère de la mesure de l’exécution réelle durant la période d’exposition limitée.

Ces lacunes doivent influencer la réponse à incident. Les équipes doivent éviter d’affirmer une infection au seul motif qu’un projet dépend d’une crate historiquement affectée. Elles doivent déterminer si une version affectée a été résolue ou compilée sur une machine donnée.

L’erreur inverse est plus dangereuse. Une équipe ne devrait pas écarter l’événement parce que les versions malveillantes ont été rapidement supprimées. Les caches locaux, les journaux CI, l’historique des lockfiles, la télémétrie des endpoints et l’activité des identifiants peuvent conserver des indices que les manifests actuels ne montrent plus.

Les développeurs ayant compilé une version affectée devraient traiter l’environnement concerné comme potentiellement compromis. Supprimer une crate n’annule pas le code qui a déjà été exécuté. Les secrets accessibles depuis cette machine peuvent devoir être révoqués depuis un appareil distinct et fiable.

La campagne remet également en cause l’hypothèse selon laquelle l’authentification multifacteur suffirait à résoudre la sécurité des comptes. La MFA réduit de nombreuses attaques contre les identifiants, mais un malware exécuté sur un poste de travail authentifié peut voler des sessions ou agir via les accès existants.

Une authentification plus robuste des packages reste importante. Des identifiants adossés à du matériel, une portée minimale des tokens, des accès de publication à courte durée de vie et la séparation entre la navigation quotidienne et les opérations de publication peuvent réduire l’exposition. Aucun de ces éléments ne rend l’ingénierie sociale sans importance.

La véritable frontière de sécurité traverse les personnes, les endpoints, les systèmes d’identité et les registres. Protéger uniquement la connexion au registre laisse trop de voies alternatives vers l’autorité de publication.

C’est la leçon durable de Be alert: targeted attacks on prominent Rustaceans. L’attribution peut rester non résolue tandis que les défenseurs agissent sur le mécanisme confirmé et l’impact démontré.

Ce que les mainteneurs et les équipes d’ingénierie doivent surveiller ensuite

Les prochains signaux décisifs seront des signalements supplémentaires de mainteneurs, des changements dans les contrôles de publication des packages et des preuves reliant de nouvelles sollicitations à une infrastructure de malware connue.

Tout d’abord, surveillez d’autres divulgations de propriétaires de crates Rust. Des signalements distincts mentionnant les mêmes problèmes de réunion, identités d’entreprise, commandes de presse-papiers ou modèles de projet renforceraient l’hypothèse d’une opération coordonnée.

Des signalements identifiant des malwares différents ou des objectifs sans lien affaibliraient la théorie d’une campagne unique. Ils indiqueraient néanmoins que plusieurs groupes considèrent les mainteneurs open source comme de précieux intermédiaires d’accès.

Les mainteneurs devraient conserver les e-mails suspects, liens de réunion, domaines, profils, adresses de dépôt et horodatages. Ces détails aident les équipes de réponse à comparer les infrastructures sans obliger chacun à formuler ses propres affirmations d’attribution.

Ensuite, observez comment crates.io et d’autres registres ajustent les contrôles de publication. Les verrouillages de comptes et la suppression de packages ont limité cet incident, mais sont intervenus après l’apparition des versions malveillantes.

Les futurs contrôles pourraient se concentrer sur des comportements de publication inhabituels. Un package publiant sa toute première dépendance, retirant plusieurs versions stables ou ajoutant des composants de compilation dotés de capacités réseau inattendues présente un schéma susceptible d’être examiné.

Les registres doivent équilibrer l’intervention avec l’indépendance des mainteneurs open source. Des frictions excessives peuvent retarder des publications d’urgence légitimes ou imposer davantage de travail à des bénévoles déjà très sollicités.

Le critère pertinent est de savoir si de nouveaux contrôles interrompent les changements à haut risque sans rendre la maintenance courante ingérable. C’est un arbitrage entre l’autonomie de publication et le confinement à l’échelle de l’écosystème.

Troisièmement, surveillez des liens techniques plus solides entre les approches sociales et les malwares récupérés. La correspondance de domaines, certificats de charge utile, chemins de commande, artefacts source ou infrastructures d’hébergement renforcerait l’attribution.

Une connexion confirmée à un opérateur établi pourrait améliorer la détection dans l’ensemble des écosystèmes. L’absence d’une telle connexion suggérerait que les techniques se propagent parmi plusieurs groupes.

Les organisations d’ingénierie n’ont pas besoin d’attendre ces réponses. Elles peuvent examiner qui détient les droits de publication des packages, où résident les identifiants de publication et si ces identifiants partagent un poste de travail avec la navigation quotidienne et les appels vidéo.

Les équipes devraient également savoir quelles compilations ont été exécutées durant la fenêtre d’exposition d’août. Les versions malveillantes étaient arrayref 0.3.10, internment 0.8.7 et append-only-vec 0.1.9. Toute apparition de proc-macro1 mérite une investigation.

Cette revue devrait inclure les exécuteurs CI et les caches de développement locaux, et pas seulement le dépôt actuel. Un lockfile nettoyé peut masquer une exécution antérieure si les archives historiques sont ignorées.

Les organisations peuvent en outre examiner les alertes liées à des connexions sortantes inattendues, de nouveaux mécanismes de persistance, des accès inhabituels au navigateur et une utilisation inexpliquée d’identifiants. Une exécution confirmée devrait déclencher une rotation des identifiants et une reconstruction à partir de systèmes connus comme sains.

Les mainteneurs confrontés à de nouvelles opportunités devraient séparer la vérification sociale de l’évaluation technique. Vérifiez une entreprise par des canaux indépendants, créez la réunion via un service de confiance et refusez les codecs personnalisés ou les commandes de terminal copiées.

Les dépôts inattendus doivent être traités comme des logiciels non fiables. Leurs instructions visant à compiler, tester ou lancer le projet sont des demandes d’exécution de code, même lorsqu’elles sont présentées comme des tâches d’entretien ordinaires.

La question finale n’est pas de savoir si Rust reste sûr en tant que langage. La sûreté mémoire ne peut empêcher un script de compilation de faire exactement ce que le système d’exploitation autorise.

La question est de savoir si l’écosystème peut protéger les mainteneurs dont l’autorité est devenue une cible de grande valeur. Restez vigilants : les attaques ciblées contre des Rustaceans de premier plan devraient inciter chaque équipe d’ingénierie à identifier ces personnes avant qu’un autre attaquant ne le fasse. Passez en revue les accès de publication, isolez les identifiants de publication et facilitez le signalement des sollicitations suspectes.