Plus de 100 000 dépôts infectés découverts sur GitHub

 (apiiro.com)
1 points par GN⁺ 2024-03-01 | 1 commentaires | Partager sur WhatsApp
  • Une campagne de confusion de dépôts (repo confusion), lancée mi-2023, connaît une résurgence : plus de 100 000 dépôts contenant des charges malveillantes similaires ont été détectés sur GitHub
  • Les attaquants créent des copies malveillantes ressemblant à des dépôts légitimes afin d’induire les développeurs en erreur, en combinant clonage, insertion de loader, réimportation, fork massif et promotion discrète
  • Lorsqu’un dépôt malveillant est exécuté, du code Python et des binaires sont téléchargés après une obfuscation en 7 étapes, puis des données sensibles sont dérobées, notamment des identifiants, mots de passe de navigateur et cookies
  • Même si GitHub supprime automatiquement la plupart des forks, les dépôts ayant échappé à la détection et les versions téléversées manuellement restent en ligne ; si seulement 1 % survit, des milliers de dépôts malveillants demeurent accessibles
  • Le flux d’attaque se déplace des packages malveillants PyPI vers les dépôts GitHub, faisant de la supply chain logicielle hors gestionnaires de paquets une surface d’attaque directe

Mode opératoire de l’attaque par confusion de dépôts

  • La confusion de dépôts ressemble à la dependency confusion dans la mesure où elle pousse l’utilisateur à télécharger un dépôt malveillant au lieu d’un dépôt légitime
  • La différence se situe au niveau du point d’exploitation
    • La dependency confusion exploite le fonctionnement des gestionnaires de paquets
    • La confusion de dépôts repose sur le fait qu’une personne choisisse par erreur un dépôt qui semble similaire
  • Cette campagne augmente les chances d’infection en diffusant massivement des dépôts malveillants sur GitHub
    • Elle clone des dépôts existants comme TwitterFollowBot, WhatsappBOT, discord-boost-tool, Twitch-Follow-Bot
    • Elle insère un loader de malware dans les copies
    • Elle les téléverse à nouveau sur GitHub sous le même nom
    • Elle fork automatiquement chaque dépôt des milliers de fois
    • Elle en fait discrètement la promotion sur des forums, Discord, etc.

Déroulé après l’exécution d’un dépôt malveillant

  • Lorsqu’un utilisateur utilise un dépôt malveillant, la charge cachée lève une obfuscation en 7 étapes
  • Elle récupère ensuite du code Python malveillant et des exécutables binaires
  • Le code malveillant repose principalement sur une version modifiée de BlackCap-Grabber
  • Les données ciblées sont les identifiants de connexion de plusieurs applications, les mots de passe et cookies des navigateurs, ainsi que d’autres données confidentielles
  • Les données volées sont envoyées au serveur C&C (command-and-control) de l’attaquant, puis d’autres activités malveillantes suivent
  • L’analyse du code associé est disponible dans la technical analysis de Trend Micro

Suppression automatique par GitHub et dépôts restants

  • GitHub identifie l’automatisation et supprime rapidement la plupart des dépôts forkés
  • Toutefois, la détection de l’automatisation laisse passer de nombreux dépôts, et ceux téléversés manuellement survivent
  • La chaîne d’attaque étant automatisée à grande échelle, même 1 % restant représente des milliers de dépôts malveillants
  • Une recherche GitHub sur 🔥 2024 language:python permet de voir certains dépôts actuellement en cours de diffusion
  • En incluant les dépôts supprimés, l’échelle totale atteint plusieurs millions
    • La suppression intervient généralement quelques heures après le téléversement, ce qui rend la documentation difficile
    • De nombreux dépôts d’origine subsistent, et les suppressions ciblent surtout la fork bomb
    • Par exemple, la liste des dépôts de Mattia69 affiche dans le résumé des milliers de forks, mais ceux-ci n’apparaissent pas dans le détail des forks
  • Certains utilisateurs forkent des dépôts malveillants sans le savoir, ce qui crée aussi un effet de réseau secondaire d’ingénierie sociale

Calendrier de la campagne

  • Mai 2023 : Phylum signale des packages malveillants publiés sur PyPI
    • Ces packages contiennent les premières parties de la charge actuelle
    • Ils se propagent via des appels os.system("pip install package") implantés dans des forks de dépôts GitHub populaires comme chatgpt-api
  • Juillet-août 2023 : plusieurs dépôts malveillants sont mis en ligne sur GitHub et livrent directement la charge utile au lieu de récupérer des packages PyPI
    • Ce changement intervient après la suppression des packages malveillants par PyPI et l’attention accrue de la communauté sécurité
    • Aliakbar Zahravi et Peter Girnus de Trend Micro publient une analyse technique
  • Novembre 2023 à aujourd’hui : plus de 100 000 dépôts contenant des charges malveillantes similaires ont été détectés, et leur nombre continue d’augmenter
  • Les raisons pour lesquelles cette méthode est avantageuse pour les attaquants sont claires
    • La taille de GitHub rend les instances de masse relativement petites et difficiles à détecter
    • Contrairement aux attaques précédentes, aucun gestionnaire de paquets n’intervient, si bien qu’aucun nom explicite de package malveillant ne reste comme indicateur
    • Les dépôts ciblés relèvent de petites niches peu populaires, ce qui facilite le clonage par erreur d’un dépôt d’usurpation malveillant par les développeurs

Du gestionnaire de paquets au SCM

  • Le passage de packages PyPI malveillants à des dépôts GitHub malveillants s’inscrit dans une tendance observée sur plusieurs gestionnaires de paquets et plateformes SCM
  • Alors que la communauté sécurité se concentre davantage sur les gestionnaires de paquets, le vecteur d’attaque s’est déplacé ailleurs
  • GitHub et les plateformes similaires facilitent la création automatisée de comptes et de dépôts, et offrent des API pratiques ainsi que des rate limits souples et faciles à contourner
  • La possibilité de se cacher parmi d’innombrables dépôts fait des SCM une cible intéressante pour infecter discrètement la supply chain logicielle
  • Les campagnes de dependency confusion, le code malveillant dans les registres de packages et la diffusion de code malveillant via SCM montrent que, malgré de nombreux outils et mécanismes de sécurité, la sécurité de la supply chain logicielle reste fragile

Indicateurs pour vérifier une infection

  • Il faut rechercher les motifs suivants dans le code Python et examiner les correspondances
    • exec(Fernet
    • exec(requests
    • exec(__import
    • exec(bytes
    • exec("""\nimport
    • exec(compile
    • __import__("builtins").exec(
  • Il faut vérifier si des dépôts liés à l’automatisation de plateformes sociales, aux bots ou aux jeux sont présents en local, puis les supprimer
  • S’ils doivent absolument être utilisés, il faut les réinstaller, mais en vérifiant soigneusement leur provenance ou en les exécutant dans une sandbox
  • Si vous avez pu cloner ce type de dépôt, il faut considérer que les cookies, identifiants et clés suivants ont été volés et réagir en conséquence
    • Navigateurs : services financiers, services de messagerie, services de cryptomonnaie, Amazon, eBay, AliExpress, Facebook, Instagram, Twitter, Youtube, Discord, TikTok, Telegram, Twitch, Steam, Yahoo, ExpressVPN, Spotify, services de streaming
    • Applications : Exodus, Atomic Wallet, Guarda, Coinomi, Ethereum
  • La liste complète des checksums de fichiers est difficile à traiter de manière pratique, mais certains éléments communs sont disponibles dans le graphe VirusTotal
  • Après notification, Cloudflare a désactivé les enregistrements DNS des adresses malveillantes identifiées

Défense et réponse

  • GitHub a été notifié et a supprimé la plupart des dépôts malveillants, mais la campagne se poursuit
  • Les attaques visant à injecter du code malveillant dans la supply chain sont de plus en plus répandues
  • Il existe de nombreuses solutions pour détecter les malwares au niveau système et réseau, mais la supply chain reste pour les attaquants une surface d’attaque vaste et rentable
  • Si vous découvrez un dépôt malveillant, qu’il fasse ou non partie de cette campagne, vous pouvez le signaler via le rapport d’abus ou de spam de GitHub
  • Apiiro a construit un système de détection de code malveillant qui surveille les bases de code connectées
    • Analyse de code basée sur les LLM
    • Décomposition du code en graphe complet du flux d’exécution
    • Moteur heuristique
    • Décodage, déchiffrement et désobfuscation dynamiques
  • Sans surveillance des charges malveillantes injectées, la sécurité d’une organisation dépend de conditions telles que la capacité des développeurs à ne pas choisir un mauvais dépôt presque identique, l’absence totale d’erreurs de configuration CI/CD et du code tiers 100 % sûr
  • Au-delà de la détection et de la collecte classiques de vulnérabilités, il faut une approche qui mette en lumière la prochaine génération de risques liés à la supply chain logicielle et aux applications

À lire aussi

1 commentaires

 
GN⁺ 2024-03-01
Avis sur Hacker News

  • Au-delà de l’avertissement général selon lequel il faut se méfier du code provenant de dépôts publics ou de sources externes et vérifier l’arbre des dépendances, je me demande quel impact pourrait avoir la présence massive de code malveillant dans des dépôts publics sur les LLM et les outils d’automatisation entraînés sur ce contenu
    Il semble aussi possible que, lorsque des outils comme Copilot génèrent de longues réponses de code, des parties malveillantes s’y glissent par hasard
    On observe déjà fréquemment des choses comme de simples vulnérabilités d’injection

    • Ce qui m’inquiète davantage qu’une porte dérobée se retrouve par hasard dans la sortie d’un LLM, c’est que des services de renseignement implantent des portes dérobées dans les sorties des LLM
      Ce n’est peut-être pas le cas aujourd’hui, mais cela paraît tout à fait plausible d’ici quelques années
    • Les LLM ne se contenteront probablement pas de coller du code vulnérable présent dans leurs données d’entrée ; ils créeront aussi eux-mêmes de nouvelles vulnérabilités
      L’IA ne donne aucune garantie d’exactitude
    • Je viens de publier un sujet lié aux LLM sur la prise de contrôle du bot de conversion safetensors de Hugging Face : https://news.ycombinator.com/item?id=39549482
      Il montre qu’un attaquant peut prendre le contrôle du bot de service connecté à l’espace de conversion Hugging Face Safetensors, un service populaire qui convertit les modèles de machine learning non sûrs de l’écosystème en versions plus sûres
    • Le risque existe, mais il ressemble à celui d’accepter sans revue une PR d’un collègue contenant du code vulnérable copié quelque part
      Si l’on veut utiliser des LLM, il faut investir davantage d’efforts dans la revue de code, et je pense que ce compromis en vaut la peine
    • Le nombre d’échantillons détectés dans cette campagne est si élevé que le risque est plus réaliste qu’on ne pourrait le penser
      Cela dit, pour qu’il débouche sur un incident réel, il y a principalement deux obstacles : le fait que le générateur reçoive des consignes internes lui demandant d’éviter ce type de code, et le fait que, par nature, un LLM a peu de chances de répéter tel quel l’adresse réelle d’un attaquant
      Malgré tout, divers vecteurs d’attaque comme les bind shells, les dénis de service ou l’exfiltration sur site restent possibles

  • GitHub est en train d’échouer d’une manière similaire à Usenet
    N’importe qui peut créer un dépôt, et rien ne distingue les dépôts officiels des dépôts de spam
    Comme Amazon, qui voulait devenir « le magasin de tout » et s’est heurté au fait que « 90 % de tout est de la camelote », devenant ainsi une boutique majoritairement remplie de déchets, GitHub doit décider si son produit est un « dépôt pour tout le monde » ou du « code fiable »
    Par exemple, même le PG JDBC officiel ne semble comporter aucun élément qu’un spammeur ne pourrait pas reproduire ; comment savoir que ce n’est pas un dépôt infecté : https://github.com/pgjdbc

    • GitHub semble avoir choisi le dépôt pour tout le monde il y a déjà 16 ans, au moment même où l’entreprise a démarré
    • Pour une bibliothèque Java, on la télécharge généralement depuis Maven Central, pas depuis GitHub
      Sonatype exige une preuve de propriété du domaine inversé utilisé dans le groupId, ici org.postgresql
      La méthode est expliquée ici : https://central.sonatype.org/faq/how-to-set-txt-record/
      Pour être encore plus rassuré, comme tous les artefacts publiés sur Maven Central sont signés, on peut aussi vérifier la signature GPG, mais l’inconvénient est qu’il faut obtenir la clé utilisée par Postgres pour la signature via un canal indépendant de Sonatype
      Dans le cas de PG, une recherche rapide ne m’a pas permis de trouver la clé
    • Je crois que l’on ne se rend pas bien compte à quel point ce chiffre est faible
      GitHub compte environ 500 millions de dépôts, donc ce niveau est en réalité plutôt bon
    • Plus de 100 000 dépôts infectés, ce n’est pas bon, mais cela ne signifie pas pour autant que GitHub a échoué
      Un développeur qui utiliserait un dépôt infecté trouverait de toute façon quantité d’autres moyens de créer un produit non sécurisé, même si de tels dépôts n’existaient pas sur GitHub
    • En prouvant la propriété d’un domaine, on peut obtenir un badge vérifié sur la page de l’organisation, ce qui augmente nettement la confiance
      Il semble simplement que l’organisation donnée en exemple ne l’ait pas fait

  • Les problèmes de chaîne d’approvisionnement sont vraiment un casse-tête
    Je ne cible pas directement les releases npm, mais j’ai créé une release npm pour surveiller avec socket.dev un projet de navigateur web virtualisé léger appelé BrowserBox
    Ce projet compte lui aussi environ 800 dépendances en incluant toutes les dépendances transitives, alors qu’il n’utilise que 19 dépendances de premier niveau, ce qui reste relativement léger à l’échelle de l’ensemble de la stack
    J’envisage maintenant de faire un snapshot des 800 dépendances dans l’espace de noms @browserbox de npm, puis de suivre les vulnérabilités détectées et de les corriger
    Ça peut sembler délirant, mais c’est la situation actuelle, et au moins ainsi on peut garantir directement, au niveau de sécurité de l’entreprise, les vulnérabilités de chaîne d’approvisionnement côté Node/JS
    https://socket.dev
    https://github.com/BrowserBox/BrowserBox

    • Je ne sais pas dans quelle mesure npm propose la même chose, mais crates.io et cargo disposent d’outils comme cargo audit et cargo deny pour vérifier les CVE de l’arbre de dépendances dans le pipeline
      Comme le fichier de verrouillage conserve le sha256 de tout l’arbre, même si le dépôt est piraté, il n’est pas nécessaire de le mettre en miroir pour éviter les modifications
      Se fixer sur une version avec quelques mois de retard sur la plus récente semble être un bon équilibre pour éviter les nouvelles CVE sans rester bloqué sur des versions trop anciennes qui obligeraient ensuite à tout corriger d’un coup
      Le nombre de téléchargements me paraît être un indicateur acceptable par rapport à des dépendances de premier niveau ayant un objectif similaire, mais c’est un jugement subjectif
      Austral utilise des types linéaires pour accorder des permissions fines aux dépendances
      Par exemple, une bibliothèque graphique n’a pas besoin d’accès aux fichiers, et une bibliothèque de transport réseau n’a pas besoin d’accès au micro
      Ce n’est qu’une mesure d’atténuation, mais j’aimerais voir cela dans d’autres langages
    • L’expression « seulement environ 800 dépendances » fait un peu froid dans le dos
      Il y a une dizaine d’années, après être passé de .NET à Java, j’ai été surpris par l’augmentation considérable du temps consacré à l’enfer des dépendances, et aujourd’hui, dans les projets Java comme Python, le temps passé sur les mises à jour de vulnérabilités et les problèmes de dépendances est effrayant
      Si ce problème était moins marqué dans .NET, c’est probablement parce que l’adoption de la gestion automatique des packages y est arrivée relativement tard et que NuGet était encore assez jeune ; à l’époque, beaucoup de projets ne l’avaient pas encore adopté, ce qui entretenait une forte culture d’évitement des énormes arbres de dépendances transitives
      Les récents problèmes de Boeing me semblent du même ordre
      Au fil des dernières décennies, la production a été de plus en plus confiée à des fournisseurs externes et l’optimisation des coûts est devenue centrale, rendant la gestion de la chaîne d’approvisionnement de plus en plus difficile ; à grande échelle, cela ressemble à la culture de la chaîne d’approvisionnement dans l’ingénierie logicielle moderne
      Lorsque je travaillais dans une société financière qui interdisait les gestionnaires de packages pour des raisons de sécurité de la chaîne d’approvisionnement, la gestion des dépendances était ce qu’il y avait de moins pénible, et les problèmes de qualité étaient aussi les plus rares
      Du code qui ne change jamais tant qu’on ne le modifie pas explicitement a des avantages
      Nous réimplémentions nous-mêmes beaucoup de choses que d’autres auraient récupérées sous forme de packages, mais comme nous ne faisions que le nécessaire et appliquions des standards de code plus élevés, c’était plus facile à comprendre, déboguer et modifier
      Le coût initial d’écriture est ponctuel et s’amortit bien, tandis que le coût récurrent de gestion d’un code qui essaie de tout faire pour tout le monde devient plus élevé à long terme et s’accumule généralement
      « Simple Made Easy » de Rich Hickey illustre bien ce phénomène : simple et facile ne sont pas la même chose, et les options simples peuvent sembler plus difficiles au départ, mais lorsque les effets secondaires s’accumulent, elles deviennent plus faciles à long terme

  • J’avais déjà remarqué ce genre de choses en tombant par hasard sur des dépôts similaires
    Même avant, je n’exécutais pas le code de n’importe quel dépôt, mais désormais, même si je fais confiance au dépôt et à son propriétaire, je lance une VM sandboxée
    De nos jours, un développeur devrait sans doute séparer clairement au moins trois environnements : travail, loisirs et usage personnel

    • Le simple fait de dire que les développeurs devraient séparer leurs environnements de travail, de loisirs et personnels montre à quel point la complexité de la vie numérique a atteint un niveau qui fait douter de sa soutenabilité à long terme
    • Chaque année, Qubes ressemble davantage à un choix raisonnable
    • Je fais aussi ça maintenant, et pas seulement à cause des logiciels potentiellement malveillants
      Certains projets ne sont pas malveillants, mais sont bancals par conception ou écrits de façon stupide
      Un programme que j’ai lancé récemment a ajouté trois lignes à ~/.bashrc avant même que je lui demande quoi que ce soit, et je ne m’en suis rendu compte que quelques jours plus tard
      Je ne comprends pas quel développeur peut considérer ça comme une bonne idée, et c’est pour cela que j’utilise désormais une sandbox à chaque fois que j’exécute du code externe
    • Cela ressemble à une bonne raison d’utiliser Qubes OS, où tout s’exécute par défaut dans une VM
      C’est mon OS du quotidien
    • Ne pas mélanger environnement professionnel et personnel me paraît être la base absolue
      Il existe vraiment des employeurs qui autorisent ça ?

  • Je me demande quels outils sont utilisés au travail pour éviter ce genre de problème, et si les gens sont satisfaits de leur configuration actuelle
    Nous développons, avec une équipe assez réduite, un SDK très téléchargé chaque semaine, et nous avons évalué Snyk, aikido.dev, des solutions basées sur Renovate, etc., mais il n’est pas clair qu’elles aident vraiment face à ce type de problème
    Comme nous sommes encore une petite équipe, gérer un outil avec beaucoup de faux positifs comme Snyk est aussi une charge

    • Plutôt que d’utiliser directement des dépôts GitHub, nous utilisons des paquets publics provenant de dépôts de paquets classiques comme NuGet, PyPI ou npm, et nous plaçons Repository et Firewall de Sonatype comme proxy entre nous et les dépôts de paquets
      Sonatype analyse tous les paquets, y ajoute diverses métadonnées, puis on définit dans Firewall des politiques utilisables pour filtrer le reste
      Cela ne fonctionne que pour les dépendances publiques, mais après plusieurs années d’utilisation, ça marche plutôt bien
      Jusqu’à présent, nous n’avons pas eu de problème de malware, les paquets comportant des vulnérabilités connues ne peuvent pas entrer dans la base de code, et nous recevons des alertes si une vulnérabilité est découverte dans ce que nous utilisons
    • Au travail, nous utilisons Semgrep Supply Chain et nous en sommes assez satisfaits
      Il classe les vulnérabilités de la chaîne d’approvisionnement qu’il détecte en atteignables, non atteignables et indéterminées, ce qui rend le tri beaucoup plus facile et réduit fortement le temps nécessaire pour évaluer de nouvelles vulnérabilités
    • Dans ce sous-fil, beaucoup semblent confondre malware et vulnérabilités
      Les fournisseurs mentionnés ne détectent pas le code malveillant, ils ne détectent que des vulnérabilités
      Même avec une bonne détection des vulnérabilités, vous n’êtes toujours pas protégé contre du code malveillant introduit dans votre base de code
    • Nous développons Packj, un outil open source qui détecte les paquets PyPI/NPM/Ruby/PHP/Maven/Rust risqués, par exemple les paquets publiquement malveillants, abandonnés ou de typosquatting
      Il effectue des analyses statiques, dynamiques et de métadonnées, et signale les paquets dangereux en vérifiant plus de 40 propriétés, comme l’exécution de shell, l’utilisation de clés SSH, les communications réseau ou l’usage de decode+eval
      https://github.com/ossillate-inc/packj
    • Trivy mérite qu’on s’y intéresse
      Jusqu’à présent, il a plutôt bien fonctionné
      https://trivy.dev/

  • Je me demande si la pratique consistant à récupérer avec curl un script d’installation shell et à l’exécuter avec sudo va bientôt disparaître
    Un mode du genre « pour installer notre logiciel, exécutez curl [https://somesite/install.sh](<https://somesite/install.sh>;)' | sudo sh » semble s’articuler très facilement avec le code infecté mentionné dans l’article

    • En tant qu’auteur de cette étude, je peux le confirmer
      Notre système recense chaque semaine environ 100 occurrences du motif mentionné, et environ 3 % sont malveillantes
      J’aimerais voir cette pratique disparaître
    • Malheureusement, npm i dispose des mêmes privilèges
      Parmi les outils courants de téléchargement de dépendances, le seul que je connaisse où du code hostile n’est pas exécuté au moment de l’installation ou du build est à peu près go get
      Il nous faut au minimum de meilleurs outils pour travailler dans des sandboxes, afin de compartimenter l’explosion
      L’approche de ChromeOS, où « une machine virtuelle peut ouvrir des fenêtres Wayland sur le bureau principal », est élégante, mais la dernière fois que j’ai regardé, ce code n’était pas particulièrement propre ni réutilisable
    • Pour ce type d’exemple, il vaut mieux utiliser example.com
      C’est un domaine réservé à cet usage : https://www.rfc-editor.org/rfc/rfc2606.html#section-3
    • Ce n’est pas vraiment pire que les alternatives réalistes : « ajoutez le dépôt de la distribution et faites-lui confiance », « téléchargez le .deb/.rpm/l’installateur », ou, au pire, « faites confiance à un paquet empaqueté par un tiers plutôt que par l’éditeur »

  • Avec npm, on peut atténuer l’exécution de code malveillant grâce à --ignore-scripts
    https://blog.uirig.com/getting-rid-of-npm-scripts

    • En contrepartie, le code malveillant téléchargé peut s’exécuter en environnement de production
      Avec un peu de chance, il aura un comportement anormal en CI et sera détecté
      La vraie solution serait un système de réputation comme https://github.com/crev-dev/cargo-crev, mais malheureusement il est très peu utilisé
    • Du point de vue de la sécurité, cela devrait être la valeur par défaut
      Le commentaire disant qu’il faut un Makefile mérite aussi l’attention

  • Avec la publication répétée de ce type de rapports, j’améliore petit à petit la sécurité de mon environnement de développement depuis quelques mois.
    J’utilise les dev containers de VSCode pour le développement : https://code.visualstudio.com/docs/devcontainers/create-dev-...
    Une fois créés, ils sont faciles à utiliser même sans grandes connaissances de Docker, et conviennent bien pour lancer des apps web/console, mais des choses comme Flutter ou Electron se sont révélées difficiles.
    Je me suis aussi habitué à GitHub Codespaces pour les petits projets : https://github.com/codespaces
    Il m’est arrivé autrefois, lors d’un entretien, de faire du live coding consistant à modifier un petit projet Node ; aujourd’hui, dans une telle situation, j’utiliserais certainement un conteneur ou Codespaces : https://www.welivesecurity.com/en/eset-research/lazarus-luri...
    Pour les bonnes pratiques npm, Node et Docker, je lis régulièrement les recommandations de l’OWASP ; pour Docker, je les applique en utilisant autant que possible de petites images et des tags d’image explicites : https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker...
    Pour les paquets npm/python, avant installation, je vérifie avec socket.dev l’accès aux variables d’environnement, les appels réseau, les attaques de chaîne d’approvisionnement, les changements récents de propriété du code, etc. ; on peut aussi désactiver globalement les scripts postinstall, comme le recommande l’OWASP : https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_...

  • Il y a moins d’un an, il y a eu un cas de dépôt contenant un virus cheval de Troie : https://github.com/orgs/community/discussions/63603

    • Le dépôt prétendait être un voleur de mots de passe ; si on l’a téléchargé et décompressé, puis qu’il a volé des informations personnelles et des fichiers, je ne vois pas vraiment où est le problème.
      Il a en quelque sorte fonctionné exactement comme le dépôt le prétendait.

  • Le simple fait d’indiquer qu’un dépôt est officiel pourrait déjà attirer une certaine attention.

    • Plus tard, GitHub pourrait même commencer à vendre ce badge bleu.
      Qu’est-ce qui pourrait bien mal tourner /s
      Cela dit, je suis d’accord pour dire que GitHub devrait mieux montrer quel dépôt est le dépôt officiel d’un projet.