C'est le troisième épisode d'une série d'articles sur le type d'attaques de la chaîne d'approvisionnement logicielle le plus répandu : celles qui abusent d'un registre public de open-source composants logiciels. Après avoir analysé dans l’épisode précédent «Anatomie des packages malveillants : quelles sont les tendances ?« Comment les acteurs malveillants injectent un comportement malveillant dans des composants publiés nouveaux ou existants, nous sommes prêts à enfiler nos vestes de lutte contre l'incendie et à examiner comment nous pouvons réussir à bloquer les logiciels malveillants diffusés de cette manière, ou bien, faire face à un cyber-incident potentiellement grave, car nous avons pris la mauvaise approche.
La plupart des professionnels de la sécurité ont des idées sur la manière de gérer cette menace. Nous avons entendu des responsables de la sécurité affirmer sans hésitation que SCA Les outils vous indiquent déjà si une version de package est malveillante. Ils peuvent également s'appuyer sur des composants logiciels connus et hautement évalués, où tout logiciel malveillant serait rapidement détecté et supprimé. Ils utilisent des versions mineures/correctifs ouvertes pour obtenir automatiquement des correctifs de vulnérabilités, ce qui constitue la méthode recommandée pour réduire les risques liés aux dépendances open source, conformément à la directive « … ».patcher tôt, patcher souvent»Principe.
Dans cet épisode, nous examinerons pourquoi ces idées sont fausses et comment ces idées fausses contribuent à la popularité de ce mécanisme d’attaque et au risque écrasant auquel sont confrontées les organisations. Nous terminerons par ce qui fonctionne et quels sont les efforts et les ressources impliqués.
Erreur commune
Au cours de notre parcours vers la sécurité logicielle, nous avons vu les techniques d'attaque évoluer et un large éventail d'idées émanant de personnes soucieuses de la sécurité. Les organisations comprennent souvent mal ce qui fonctionne contre cette menace. Nous allons donc d’abord examiner ce qui ne fonctionne pas, condensé dans la liste suivante, non exhaustive, d’idées fausses.
Idée reçue n ° 1: SCA les outils signalent déjà les composants malveillants
En Effet! Mais après coup… Quand il est probablement trop tard si l’élément a été utilisé dans une construction de logiciel, et les mauvais acteurs ont déjà pris pied dans un développeur ou CI/CD hôte. Des secrets ont peut-être été exfiltrés, des logiciels malveillants supplémentaires ont été téléchargés et installés, et peut-être que l'adversaire s'est déplacé latéralement et a déjà obtenu un accès ailleurs.
Analyse de la composition logicielle (SCA) Les outils ont été conçus pour identifier les vulnérabilités potentielles connues. Les outils modernes sont très efficaces en augmentant le rapport signal/bruit, déterminant ainsi si la vulnérabilité est réellement accessible ou exploitable. Cependant, ils sont inefficaces contre les nouveaux malwares. Considérez un composant malveillant comme une vulnérabilité zero-day : ce n'est que lorsque son comportement malveillant est détecté qu'il est signalé au registre de stockage. Après examen par une équipe de sécurité, le composant est confirmé comme malveillant et supprimé du registre. [1].
À ce moment-là, le monde (y compris SCAs) sait que l'installation ou l'utilisation du composant (ou de certaines versions d'un composant existant) n'est pas recommandée. Mais c'est le cas lorsque le composant n'est pas disponible dans le registre.. Savoir que j'ai des vulnérabilités dans des composants tiers, ou même des composants qui ont été classés comme malveillants par le registre est une bonne chose, mais malheureusement SCA ou les outils d’audit courants ne sont pas utiles dans ce contexte. Sauf si SCAL'outil /audit peut réellement savoir à l'avance qu'un composant est malveillant avant qu'il ne soit utilisé dans votre organisation.
N'oubliez pas que toute solution contre les composants open source malveillants doit les détecter à la volée, entre le moment où le composant est publié dans le registre et le moment où le composant (version) est utilisé pour la première fois dans votre organisation. Et cela inclut les composants transitifs.
Idée fausse n°2 : le contrôle des scripts d'installation au moment de la construction empêche les comportements malveillants de la part des composants open source
Divers gestionnaires de packages offrent la possibilité d'exécuter des scripts (inclus dans l'archive tar du composant [2]), pour des raisons légitimes, telles que la compilation des éléments requis sur différentes plates-formes, la génération de code ou l'exécution de tests, et nous devons tous savoir qu'ils peuvent être utilisés par de mauvais acteurs si des scripts malveillants sont inclus dans l'archive tar, ou si l'attaquant peut créer un message malveillant. script exécuté au lieu du bon.
Sachant cela, nous pouvons configurer le gestionnaire de packages pour qu'il ignore les scripts. Par exemple, avec NPM, le –Ignorer-scripts flag (ou une propriété de configuration dans le .npmrc fichier) ignore les scripts lors de l'installation. Cela peut produire certains problèmes car l'exécution de scripts est courante dans de nombreux écosystèmes : certains gestionnaires de packages n'autorisent même pas la désactivation de l'exécution de scripts (indice : invite "Quels gestionnaires de packages ne permettent pas de désactiver l'exécution des scripts d'installation ?" dans votre IA préférée). Mais cela ne protège pas en général (nous devons faire en sorte que la configuration de désactivation du saut soit partout).
Et lorsque le comportement malveillant ne se situe pas dans les scripts d’installation mais dans le logiciel à exécuter au moment de l’exécution, cette option à elle seule ne nous protège pas.
Idée fausse n°3 : l'épinglage de version empêche l'installation de composants malveillants
Il y a un compromis entre appliquer des correctifs tôt et souvent avec versions ouvertes (permettant au gestionnaire de packages d'installer automatiquement les nouvelles mises à jour lorsqu'elles sont disponibles pour les correctifs de sécurité) et épinglage de version (ayant toutes les dépendances directes et transitives pour un logiciel en version fixe). Les principes de sécurité sont tenaces et parfois contradictoires, comme c'est le cas avec « patch early, patch souvent » et « la mise à niveau ne doit pas être prise à la légère ». Certains gestionnaires de packages effectuent des mises à jour automatiques avec les plages de serveurs de la manière recommandée. Idéal si vous souhaitez également recevoir les mises à jour malveillantes ! Oui, les composants doivent être mis à jour pour recevoir des correctifs de sécurité qui corrigent les vulnérabilités le plus rapidement possible, mais… ne laissez jamais le gestionnaire de packages le faire automatiquement.
Idée fausse n°4 : l'utilisation de composants fiables est sûre. Toute version malveillante serait rapidement trouvée, divulguée et supprimée.
Pourquoi un composant est-il fiable ? Peut-être parce qu'il est très populaire, qu'il attire de nombreux regards à la recherche de vulnérabilités, qu'il bénéficie d'un grand nombre de contributeurs pour la maintenance et que plusieurs mainteneurs principaux examinent consciencieusement tous les composants. pull requests. La réalité est tout autre. Certains composants essentiels sont maintenus par un seul développeur non rémunéré. Les frameworks largement utilisés ont quelques contributeurs réguliers, avec un nombre rapidement décroissant de commits par responsable (les projets populaires ont une longue queue de contributeurs qui effectuent des tâches en voiture commit et ne reviens jamais). Et les projets populaires avec un seul responsable sont nombreux.
Imaginez-vous en train de dire "Oh, nous utilisons Spring Boot / Angular / React / PyTorch / images Docker de base officielles, donc le risque dont vous parlez est assez faible." C'est peut-être vrai, nous, les fournisseurs de sécurité, faisons constamment des alarmistes, et interférer avec les équipes de développement pour atténuer un risque discutable est un non-sens. Vous pourriez être tenté de passer directement au paragraphe sur l’acceptation des risques (dans la section suivante) et tout est fait. Malheureusement, les composants les plus populaires sont des cibles pour les mauvais acteurs, et par exemple, le populaire La bibliothèque PyTorch a été attaquée dans le passé.
« Rapidement trouvé, divulgué et supprimé ». Il faut plusieurs jours pour qu'un nouveau composant malveillant soit supprimé du registre public. Les registres sont prudents quant à la suppression d’une version d’un composant, pour le bien. Notre expérience est qu'une fois signalé de notre côté, le délai médian nécessaire au registre pour supprimer la version concernée est de 39 heures, soit plus d'un jour et demi. Certains composants malveillants se trouvent une semaine après notre signalement initial dans le registre avant leur suppression. Et dans certains cas, le composant n'est supprimé qu'après qu'une victime ou une société de réponse aux incidents a signalé un incident impliquant le composant.
Ce qui ne fonctionne PAS contre les composants malveillants
Toute approche non spécifique échouera lamentablement. C’est une certitude, vous ne proposez pas de contre-mesures efficaces face au risque associé à cette menace.
Traditionnel SCA Les outils vous informent sur les logiciels malveillants connus, mais leur fenêtre d'exposition est large. À moins d'effectuer une détection proactive des logiciels malveillants avec blocage forcé des composants malveillants, ils ne sont pas efficaces contre cette menace.
La désactivation des scripts d'installation pourrait aider, mais doit être appliquée partout où un composant doit être installé. Idem avec l'épinglage de version, car les versions ne peuvent pas être épinglées pour toujours à partir d'un état initial sûr.
Il est naïf et risqué de supposer que les composants populaires reçoivent suffisamment d’attention pour ne pas pouvoir adopter un comportement involontaire lors d’une attaque de la chaîne d’approvisionnement sans une détection presque instantanée pour éviter tout dommage. Vous ne voulez pas vivre à la limite, n'est-ce pas ?
Si vous vous arrêtez à ce stade, alors acceptation du risque c'est la seule chose que vous pouvez faire : c'est un decisIl s'agit d'une information qui doit être documentée dans votre modèle de menace/évaluation des risques, y compris la justification de l'acceptation du risque et ses implications potentielles. Sensibilisez-la en la communiquant à la direction et aux autres parties concernées. Certains contingence Cela pourrait être planifié lorsqu’un composant malveillant est installé ou inclus dans votre logiciel, mais cela est difficile car les attaquants ont de nombreuses voies à suivre. Les détails d'une attaque de chaîne d'approvisionnement basée sur l'utilisation d'un composant malveillant modifieront radicalement la divulgation publique de l'incident, qui est probablement obligatoire en vertu du cadre réglementaire de votre organisation. Vous pouvez également adresser contrôles compensatoires or risque de transfert par exemple avec une assurance.
Cependant, il existe des contrôles qui répondent à la menace et doivent être envisagés si vous n'êtes pas satisfait de l'acceptation du risque. Veuillez continuer à lire.
Qu'est-ce qui fonctionne contre les attaques utilisant des composants malveillants
Gestion des versions solides
L'épinglage de version avec des changements de version contrôlés et informés est la voie à suivre, pour équilibrer la nécessité de supprimer les vulnérabilités sans recevoir de logiciels malveillants. Mais rappelez-vous l’idée fausse n°3 : l’épinglage de version ne suffit pas à lui seul à bloquer le code malveillant provenant des nouvelles versions, car vous devrez à l’avenir mettre à jour les versions dans toute dépendance directe ou indirecte. À ce moment-là, vous avez besoin de preuves suffisamment solides que toutes les versions modifiées ne contiennent pas de logiciels malveillants.
Alerte Précoce
Une approche au problème des composants malveillants est un système d'alerte précoce (nommé ici comme Alerte précoce contre les logiciels malveillants ou MEW), où les nouvelles versions publiées (pour les composants nouveaux ou existants) sont analysées par un moteur de détection qui, lorsque suffisamment de preuves sont trouvées, peut classer la nouvelle version comme potentiellement malveillante.
L'automatisation est ici essentielle, car il est impossible de revoir manuellement tous les nouveaux composants au rythme de publication actuel. Ainsi, le moteur de détection doit combiner diverses techniques, notamment l'analyse statique, dynamique et des capacités, la réputation des utilisateurs et les preuves provenant de divergences entre les métadonnées du composant et le contenu de l'archive tar, ou entre l'archive tar et le référentiel source où le composant est censé être utilisé. vient de.
Il y a un zone sombre entre le moment de la publication et le moment où le moteur analyse le contenu du composant, mais il ne doit pas dépasser quelques minutes. Le schéma peut être modifié, par exemple en attendant que les nouveaux composants soient analysés avant de permettre leur installation et leur utilisation dans la construction du logiciel. pipelines, ou analysez-les à la demande en cas de besoin. Un composant à une version donnée est immuable [3], il ne doit donc être analysé qu’une seule fois.
Une automatisation complète n'est pas possible et un examen de sécurité des composants potentiellement malveillants est nécessaire. Méfiez-vous des partisans de la panacée numérique: L'IA et le Machine Learning ne sont pas suffisamment développés pour avoir le dernier mot lorsqu'il s'agit de confirmer si un composant suspect contient un malware. Bien sûr, l’apprentissage automatique joue un rôle clé dans le moteur de détection en classifiant le composant d’entrée à partir des preuves brutes capturées, mais une fois le composant « mis en quarantaine », le dernier mot revient à l’examen manuel par une équipe de sécurité expérimentée dans les composants malveillants. Cela confirme tout logiciel malveillant potentiel ou le reclasse comme sûr. Et la période est de l’ordre de quelques heures.
Le registre signale la version/le composant malveillant ; le registre effectue ensuite son examen pour confirmer et procède à la divulgation publique et à la suppression du registre. Certains registres conservent un package de détention de sécurité. La plage de temps ici correspond aux jours ou aux semaines écoulées depuis la publication, qui est le 'temps d'arrêt' ou 'fenêtre d'exposition' pour la plupart des composants malveillants.
Est-il possible de savoir si une version d'un composant est malveillante ?
Ainsi, pour un avertissement précoce, nous devons donner une réponse satisfaisante à cette question : comment puis-je savoir qu'une bibliothèque ou un package est (non) malveillant ? Comment rassembler suffisamment de preuves d’un comportement malveillant ? Possible, mais difficile, car les adversaires font preuve de beaucoup d’ingéniosité pour éviter d’être détectés. Il existe différentes approches, chacune présentant des avantages et des inconvénients.
Analyse statique peut examiner tous les chemins d'exécution, rechercher les techniques utilisées par les attaquants sans exécuter le composant et effectuer des tâches de prétraitement telles que la désobscurcissement ou le déchiffrement. Alors que les attaquants tentent de cacher leurs méfaits, les tentatives d’obscurcissement sont en effet une preuve de malware (mais notez que des composants légitimes obscurcissent le code pour préserver la propriété intellectuelle, contredisant «open sourceSeule une minorité d'attaques très sophistiquées avec une forte obfuscation nécessitent un sandboxing, mais une telle obfuscation est un signe révélateur de malveillance. Veuillez noter que les attaques conventionnelles SAST les outils ont été conçus pour les vulnérabilités involontaires, et non pour des intentions malveillantes comme les portes dérobées.
Analyse dynamique exécute le composant et examine la réponse en instrumentant le runtime, généralement en fournissant un environnement en bac à sable. Un comportement malveillant déclenché dans certaines conditions peut passer inaperçu : veuillez noter que les logiciels malveillants peuvent utiliser des techniques d'évasion telles que Évasion de virtualisation/sandbox à activer uniquement lorsqu'il n'est pas sous surveillance, et également un signe révélateur d'activité malveillante pour tout moteur d'analyse statique.
Analyse des capacités considère ce que fait le composant : où il se connecte, à quels fichiers il accède, quelles commandes ou programmes sont exécutés, les E/S du terminal ou du périphérique effectuées ou quels appels système sont invoqués. Cette empreinte de comportement pourrait être comparée (pour un composant existant) entre les versions, de sorte que lorsqu'un comportement inattendu est détecté, cette preuve pourrait éveiller des soupçons sur une activité malveillante potentielle injectée dans la nouvelle version. Cette approche suit les étapes de tri que suivent les analystes de sécurité lorsqu'ils sont confrontés à des logiciels malveillants potentiels : une inspection à l'aide de instruments à cordes ou des outils similaires. Cette approche détecte les comportements malveillants quelles que soient les conditions de déclenchement et fonctionne lorsqu'aucun code source n'est disponible.
Analyse du contexte collecte des informations sur la manière dont le composant a été publié et par qui. Les campagnes des acteurs malveillants utilisent souvent un ou plusieurs nouveaux comptes utilisateur non soumis à un processus de vérification strict. Le suivi des activités passées peut donner un aperçu de l'utilisateur sous-jacent, principalement pour détecter des anomalies pouvant laisser penser à un compromis potentiel. La réputation est si difficile à gagner et si facile à perdre ! Un utilisateur sans activité passée est neutre, mais le karma poursuit le malveillant. Les hacktivistes ou les utilisateurs normaux dont les informations d’identification de publication ont été volées doivent être soigneusement suivis.
Une autre information contextuelle est toute divergence entre le référentiel source censé être utilisé pour créer l'archive tar du composant et le contenu de l'archive tar elle-même. Et aussi suivre les bonnes pratiques, comme créer des balises ou des versions dans le référentiel source correspondant aux versions du composant publiées dans le registre public. Lorsque le référentiel source à un emplacement particulier commit est étiqueté avec release, puis soudain une version ne parvient pas à le suivre, cela seul est une preuve solide que le composant pourrait être entaché : le mauvais acteur a peut-être compromis le compte utilisé pour publier le composant, mais n'a aucune autorisation d'écriture dans le code source dépôt). De nombreuses attaques sont régulièrement détectées à l'aide de ces règles : par exemple, le Attaque de grand livre pourrait être facilement détecté dans ce sens. L’analyse contextuelle identifie donc de telles anomalies dans le processus de publication.
Pare-feu de dépendance
Une approche différente consiste à disposer d'une liste blanche complète de composants pour tous les graphiques de dépendances utilisés dans votre logiciel, donc dans n'importe quelle version. pipeline exécutés dans votre organisation, seules les versions de composants approuvées peuvent être installées et utilisées. Le "pare-feu" est appliqué à l'aide d'un registre interne où les archives tar des versions de composants autorisées sont servies (mises en cache ou proxy). Veuillez noter qu'aucune liste blanche ne fonctionnera pas à moins que vous ne disposiez de la technologie permettant de classer toute nouvelle version comme raisonnablement sûre afin qu'elle puisse être ajoutée à la liste blanche.
Veuillez noter que l'alerte précoce (détection rapide dès que possible après la publication de la nouvelle version) doit être combinée avec un moyen d'utiliser ces informations de manière proactive pour bloquer le composant affectant la build. pipelines ou les machines des développeurs [4]. Nous appelons cela «pare-feu de dépendance» : un mécanisme de quarantaine pour protéger les builds automatisés contre les packages malveillants. Les packages internes et les registres d’images sont utiles pour protéger les organisations du mal extérieur, mais des preuves suffisamment solides sont nécessaires pour rendre la quarantaine efficace.
Sandbox d'exécution
Une approche alternative pour la détection au moment de la publication consiste à analyser le comportement au moment de l'exécution. L'idée est de capturer le comportement attendu du logiciel et de détecter (ou bloquer) les anomalies trouvées. Cette ligne d'action présente le problème de devoir instrumenter le runtime pour la surveillance ou le blocage, et c'est une idée prometteuse qui s'ajoutera à l'arsenal de mécanismes de protection contre les composants malveillants nuisibles.
Définir une stratégie globale
La stratégie recommandée doit combiner différentes techniques dans le processus de développement logiciel, en prenant le contrôle des mises à jour de version pour bloquer les composants malveillants entrants. Nous devons prendre en compte l’épinglage des versions pour éviter les infections automatiques lors de la mise à jour des versions afin d’obtenir des correctifs pour les vulnérabilités importantes ; une évaluation rapide et efficace des dépendances directes et indirectes lors des mises à jour de version pour avoir suffisamment de preuves qu'elles ne sont pas infectées par des logiciels malveillants. Les versions de logiciels qui dépendent de composants malveillants connus doivent être bloquées. Et tout doit être appliqué.
Utilisez l’épinglage de version, lorsque cela est possible, car cela rend les builds plus reproductibles. Épinglage de version avec modifications de version contrôlées et approuvées manuellement et assisté par une technologie d'assistance, doit évaluer si la mise à jour apporte des logiciels malveillants ou endommage le logiciel, et concilier la mise à jour pour corriger les vulnérabilités et éviter les infections par des logiciels malveillants. Les outils peuvent aider ici, en (1) donnant la priorité aux vulnérabilités vraiment importantes (atteignables et exploitables, avec un risque élevé d'être ciblé par des attaquants), (2) en sélectionnant les versions cibles qui sont compatibles avec les utilisations actuelles des composants et ne brisent pas le logiciel, (3) choisir des versions cibles qui ne contiennent pas de comportement malveillant et (4) faire de la mise à jour de version pour les dépendances directes et indirectes un jeu d'enfant, en suggérant des modifications dans les fichiers manifestes qui pourraient être rapidement approuvées. L'étape (3) nécessite des informations spécifiques sur les composants malveillants aussi proches que possible de leur heure de publication.
Ce processus de mise à jour des dépendances doit être forcée et vérifié Partout. Le processus doit être documenté et toutes les parties impliquées doivent être formées, car le développement et la création/déploiement du logiciel sont souvent externalisés. CI/CD pipelines doivent être modifiés en conséquence, afin que l'automatisation ne permette pas à une dépendance indirecte malveillante de se glisser dans la build : guardrails bloquer la construction s'il existe suffisamment de preuves de logiciels malveillants potentiels dans une dépendance est la solution recommandée.
Si votre organisation dispose d'un registre interne agissant comme un proxy de sécurité pour conserver les versions de composants autorisées, vous devez obtenir des informations sur les composants malveillants (en plus d'autres critères) pour vérifier un composant demandé avant de l'ajouter à la liste d'autorisations.
Utiliser des logiciels open source en toute sécurité n'est pas facile, et le facteur malware doit être pleinement pris en compte, avec des efforts similaires consacrés à la gestion des vulnérabilités.
Une dernière note: Provenance de la source, sous la forme d'attestations logicielles, générées au moment de la construction du composant, est un autre élément clé dans l'effort de traçabilité de l'artefact (archive tar du composant) avec les sources et le processus de construction qui l'a produit. Notez que ce lien entre l'instantané source + l'environnement de build et l'artefact logiciel associé (signé par le système de build approuvé) n'empêche pas en soi que le composant ne contienne pas de comportement malveillant, mais rend plus difficile pour les méchants d'injecter des logiciels malveillants. . Et faire de la validation de la provenance une exigence courante pour la consommation de composants open source prendra beaucoup de temps, et seulement récemment ajouté à NPM. Rendre ces systèmes de construction et de déploiement fiables inviolables, ou permettre la détection de toute falsification dans la construction est une autre histoire, qui sort du cadre de cet article.
Lectures complémentaires
Le prochain épisode Packages malveillants open source : l'approche Xygeni présentera la stratégie que nous suivons chez Xygeni pour notre Alerte précoce contre les logiciels malveillants (MEW). Les nouvelles versions de package dans les registres de packages publics et d'images sont analysées et les preuves sont obtenues à l'aide d'une combinaison d'analyses statiques, dynamiques, de capacités et contextuelles. Les preuves, combinées à la réputation des utilisateurs et à l'historique des modifications apportées aux référentiels de code source, permettent une classification entièrement automatisée d'un composant en catégories à haut risque et probablement malveillantes. Le système apprend des preuves passées recueillies à partir des packages pour réduire les faux positifs au minimum.
Les organisations abonnés reçoivent une notification d'avertissement pour les composants qu'elles utilisent, directement ou indirectement, lorsqu'une version malveillante est catégorisée. Ensuite, une analyse manuelle est effectuée par nos analystes, qui confirme ou infirme le classement. Pour les logiciels malveillants confirmés, le registre public est informé afin qu'il puisse effectuer sa propre analyse et généralement supprimer la version malveillante ou prendre des mesures supplémentaires, telles que le blocage ou la suppression du compte utilisateur en question.
Nous expliquerons comment nous aidons NPM, PyPI, GitHub et d'autres infrastructures clés de l'écosystème open source à réduire le temps d'attente pendant lequel un nouveau composant malveillant publié reste actif jusqu'à ce qu'il soit confirmé comme étant un logiciel malveillant et supprimé du registre. Et comment les organisations peuvent bénéficier du système MEW pour bénéficier d'une bien meilleure protection contre les attaques de la chaîne d'approvisionnement logicielle impliquant des composants open source.
- [1] Quoi qu'il en soit, les utilisateurs du composant doivent vérifier si l'archive tar du composant est mise en cache ou enregistrée quelque part, par exemple dans un registre interne, afin que la maladie soit éradiquée.
- [2] Le composant packagé comprend un manifeste qui déclare son contenu et ses métadonnées, son code source ou compilé, ses scripts d'installation et des éléments supplémentaires tels que des suites de tests, selon un format de packaging et généralement sous forme compressée. C'est ce qu'on appelle « l'archive tar des composants ».
- [3] Même si l'acteur malveillant peut modifier un composant publié en raison d'une violation du registre lui-même, un simple résumé cryptographique peut détecter tout changement dans l'archive une fois l'analyse effectuée.
- [4] N'oubliez pas que certains composants malveillants s'exécutent au moment de l'installation, cela peut donc affecter les nœuds de développement qui exécutent involontairement « npm install X » avec X un composant malveillant.
