Nous utilisons l'intelligence artificielle pour les traductions de sites et, bien que nous nous efforcions d'être précis, il se peut que les traductions ne soient pas toujours exactes à 100 %. Nous vous remercions de votre compréhension.
Accueil/
Blog
/
De Dune à npm : le ver Shai-Hulud redéfinit...
De Dune à npm : le ver Shai-Hulud redéfinit les risques liés à Supply Chain
par
OPSWAT
Partager cet article
Les fans de Dune reconnaîtront "Shai-Hulud" comme le nom donné aux colossaux vers sablonneux qui remodèlent le désert avec leur force irrésistible. Aujourd'hui, la communauté des logiciels libres est confrontée à une cybermenace tout aussi redoutable. Le 15 septembre, la communauté des logiciels libres a été confrontée à l'une des crises les plus perturbatrices à ce jour : un ver autoreproducteur, connu sous le nom de Shai-Hulud, s'est propagé dans l'écosystème npm, compromettant plus de 180 paquets en l'espace de quelques heures.
Les bibliothèques de confiance telles que @ctrl/tinycolor, crowdstrike-nodejs, string-kit, json-sugar, photon-colors et des fourchettes de typed.js et date et heure sont déjà touchés. Avec des millions de téléchargements chaque semaine, les entreprises intègrent sans le savoir des infections actives directement dans leur pipeline de développement.
Le ver exploite les crochets du cycle de vie de npm pour voler les informations d'identification de GitHub et du cloud public, puis utilise ces secrets pour publier des mises à jour empoisonnées dans d'autres projets.
Flux d'attaque
Une version compromise de @ctrl/tinycolor injecte un script local malveillant (bundle.js).
Le script bundle.js télécharge et exécute TruffleHog pour rechercher les secrets GitHub sur la machine de la victime.
En utilisant les secrets GitHub découverts, le script énumère les dépôts accessibles (propriétaire, collaborateur ou membre de l'organisation).
Pour chaque dépôt, il récupère la branche par défaut, crée un fichier shai-hulud et télécharge un fichier de flux de travail vers .github/workflows/shai-hulud-workflow.yml .
Le flux de travail est configuré pour se déclencher sur les événements "push". Le programme d'exécution des actions GitHub exécute le travail dans le contexte du dépôt, qui a accès aux secrets.
Le flux de travail lit les secrets GitHub et les exfiltre vers un point de terminaison contrôlé par l'attaquant.
Pourquoi cela est important aujourd'hui et à long terme
L'open source est ouvert de par sa conception. Le registre npm sert des centaines de milliards de téléchargements chaque mois, et n'importe qui peut publier un paquetage. Cette ouverture stimule l'innovation, mais elle crée également des opportunités pour les attaquants d'exploiter la confiance à grande échelle.
L'épidémie rend un fait incontournable : la confiance n'est pas permanente. Un paquet qui est sûr aujourd'hui peut être compromis demain.
Recommandation : Spécifier les versions exactes des dépendances
Nous recommandons vivement aux développeurs d'éviter d'installer automatiquement la dernière version. Ils doivent plutôt définir une version spécifique à installer, puis vérifier manuellement et mettre à niveau les versions plus récentes uniquement après vérification.
Les dépendances déclarées avec >= ou * peuvent entraîner des mises à jour non souhaitées, y compris des versions compromises. Spécifiez une version précise et révisée :
"dependencies": {
"lodash": "4.17.0"
}
Ne procédez à une mise à niveau qu'après avoir validé l'authenticité et la sécurité des nouvelles versions.
Aujourd'hui contre demain : Équilibrer l'automatisation et l'intervention humaine
Maintenant : Réponse immédiate
Suivant : La résilience à long terme
Automatisé : Auditer les dépendances npm et analyser les artefacts avec plusieurs moteurs. L'homme : Les développeurs interrompent les installations en aveugle et confirment manuellement les sources de dépendances.
Automatisé : Intégrer la validation continue du SBOM et l'analyse des logiciels malveillants dans chaque pipeline. L'homme : Les équipes de sécurité examinent régulièrement les paquets à haut risque et interviennent en cas d'anomalie.
Automatisé : Révoquer et faire pivoter les secrets exposés. L'homme : Les équipes de sécurité évaluent l'utilisation suspecte d'informations d'identification et décident des mesures de confinement.
Automatisé : Appliquer des politiques de rotation automatisées et des valeurs par défaut de moindre privilège. L'homme : Les dirigeants fixent des normes de gouvernance et veillent à ce que la confiance dans la chaîne d'approvisionnement soit respectée.
Automatisé : Appliquer l'AMF et les contrôles de signature dans CI/CD. L'homme : Les dirigeants décident quand il faut ralentir la livraison pour protéger l'intégrité.
Automatisé : Exiger des commits signés et une provenance vérifiable de la compilation pour toutes les versions. L'homme : Les conseils d'administration considèrent la confiance dans les logiciels comme une question de résilience stratégique, et non comme une case à cocher de conformité.
Une vue d'ensemble
Pour les dirigeants, cette attaque rappelle que le risque lié à la chaîne d'approvisionnement en logiciels est un risque d'entreprise. Les régulateurs attendent des contrôles vérifiables et les clients des preuves d'intégrité. Les conseils d'administration ne peuvent plus reporter la responsabilité du code qui alimente les opérations critiques.
Pour les praticiens, l'épidémie montre que les pipelines doivent évoluer. Chaque dépendance de source ouverte devrait être traitée comme non fiable jusqu'à ce qu'il soit prouvé qu'elle est sûre. Les SBOM, les analyses de logiciels malveillants et l'assainissement constituent la base, mais la sensibilisation humaine - pause, questionnement, escalade - est ce qui empêche l'automatisation aveugle d'importer le prochain ver.
Le point de vue d'OPSWAT
Renforcer la confiance dans Supply Chain
Des incidents tels que des attaques de la chaîne d'approvisionnement sur des environnements open-source tels que npm sont la preuve que les chaînes d'approvisionnement en logiciels sont désormais des charges de travail critiques. L'industrie doit passer d'une confiance aveugle à une confiance vérifiable.
George Prichici
Vice-président des produits, OPSWAT
Chez OPSWAT, nous pensons que la confiance dans la chaîne d'approvisionnement doit être construite, et non présumée. Notre approche se concentre sur la défense en profondeur :
Visibilité complète de la chaîne d'approvisionnement en logiciels avec intégration SBOM pour suivre chaque composant logiciel, identifier les vulnérabilités, gérer les risques tout au long du cycle de vie du logiciel et vérifier la provenance à chaque étape.
Multiscanning avec plus de 30 moteurs pour détecter les logiciels malveillants polymorphes et d'autres logiciels malveillants dans les paquets, en particulier dans les logiciels libres tiers.
CDR (Content Disarm and Reconstruction) pour neutraliser les charges utiles malveillantes avant qu'elles ne s'exécutent.
Des contrôles de stockage et de transfertSecure qui renforcent les limites de confiance dans les pipelines CI/CD.
Ces contrôles ne se contentent pas de détecter les risques ; ils assainissent activement les fichiers et renforcent la confiance, réduisant ainsi le risque que des incidents comme celui-ci se répercutent en aval.
Un développement rapide et une sécurité forte ne s'excluent pas mutuellement. Les équipes de développeurs ont besoin de flux d'analyse et d'approbation automatisés intégrés à la chaîne d'approvisionnement des logiciels afin de pouvoir protéger le code sans ralentir le rythme.
George Prichici
Vice-président des produits, OPSWAT
Une sécurité qui suit le rythme du développement
Avec OPSWAT, la sécurité s'intègre directement dans les flux de travail existants :
Intégration du pipeline CI/CD - Analyses automatisées et application de règles dans Jenkins, GitHub Actions, GitLab et d'autres environnements de construction.
Analyse transparente des artefacts - Validation des paquets npm, des conteneurs et des binaires dans le cadre des étapes de construction habituelles.
Génération et validation de SBOM à la demande - Produisez et vérifiez les SBOM automatiquement pour chaque version, en garantissant la provenance sans frais généraux supplémentaires.
Expérience transparente pour les développeurs - La sécurité fonctionne en arrière-plan, ne faisant apparaître les problèmes que lorsqu'une intervention est réellement nécessaire.
Crochets de remédiation automatisés - Mettez en quarantaine ou désinfectez les fichiers compromis sans interrompre les développements.
La culture de développement axée sur la rapidité ne doit pas entrer en conflit avec la validation nécessaire de la sécurité ; l'analyse automatisée et les flux de travail d'approbation devraient être incontournables, avec un impact minimal sur la vitesse de développement.
En intégrant ces capacités dans le cycle de vie des logiciels, OPSWAT aide les organisations à atteindre à la fois la vitesse de développement et la confiance vérifiable, un équilibre dont l'incident npm prouve qu'il est désormais essentiel.
Le ver npm Shai-Hulud est un signal clair des menaces qui pèsent sur les logiciels aujourd'hui. Les attaquants n'ont pas besoin de s'introduire dans votre base de code. Ils peuvent vous persuader de les installer. Vérifiez chaque artefact, intégrez la résilience à chaque étape et donnez aux gens les moyens d'agir lorsque l'automatisation ne suffit pas. Les organisations qui prennent cela au sérieux dès maintenant définiront l'avenir des chaînes d'approvisionnement en logiciels sécurisés.
Prêt à protéger votre chaîne d'approvisionnement en logiciels contre les cybermenaces les plus récentes grâce à des solutions personnalisées et parfaitement intégrées ?
Obtenez les dernières mises à jour de la société OPSWAT ainsi que des informations sur les événements et les nouvelles qui font avancer l'industrie OPSWAT
les nouvelles qui font avancer l'industrie.
Suivez OPSWAT sur LinkedIn, Facebook, Twitter et YouTube pour en savoir plus !
Restez à jour avec OPSWAT!
Inscrivez-vous dès aujourd'hui pour recevoir les dernières mises à jour de l'entreprise,
de l'entreprise, des histoires, des informations sur les événements, et plus encore.
