Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- npm audit ne peut comparer votre arborescence qu’aux données des avis de sécurité ; par conséquent, une version malveillante publiée il y a une heure ne sera pas signalée.
- Pour combler cette lacune, il ne suffit pas d'un seul outil, car les analyseurs de comportement, les vérifications de provenance et les registres filtrés couvrent chacun un aspect différent de celle-ci.
- Le contrôle qui détermine le résultat est celui qui décide, dès le départ, ce que votre build est autorisé à résoudre.
npm audit remplit parfaitement sa fonction. Il compare votre arborescence de dépendances à une base de données répertoriant les vulnérabilités connues et vous indique les correspondances. Pour tout ce qui a déjà été documenté, c'est utile. En revanche, pour tout ce qui n'a pas encore été documenté, audit ne fournit aucune information, et si vous effectuez une installation pendant cette période, le code se retrouve dans votre arborescence avant même qu'un avis de sécurité correspondant ne soit publié.
Il n'a jamais été conçu pour détecter un paquet malveillant avant que cette menace n'apparaisse dans les données d'alerte qu'il analyse. Pour trouver une alternative à npm audit qui comble réellement cette lacune, il faut se pencher sur les critères qui déterminent les versions que votre build peut résoudre, et pas seulement sur ce qui est signalé a posteriori.
Ce que vérifie réellement npm audit et quelles sont ses limites
npm audit compare votre arborescence de dépendances aux données d'alerte issues de la base de données GitHub Advisory Database, qui alimente les données d'audit de npm depuis 2021. Il s'agit d'une recherche d'alertes, et non d'une inspection du contenu des paquets ou de leur comportement en exécution. Si une version a été mise à jour il y a une heure et qu'aucune alerte ne la couvre encore, audit n'a aucun élément de comparaison avec cette version ; celle-ci ne sera donc pas signalée.
Ce n’est pas un bug. C’est la nature même de l’outil. La compromission d’Axios, qui a duré environ trois heures en mars 2026, illustre bien ce phénomène dans la pratique. Deux versions contenant une porte dérobée, les versions 1.14.1 et 0.30.4, ont été mises en ligne et se sont propagées via les installations alors que l’avis de sécurité ne mentionnait encore rien. Une fois l’avis publié, l’audit a pu signaler ces versions partout où elles s’étaient installées, y compris dans les arborescences où l’installation avait déjà eu lieu. Ce qu’il n’a pas pu faire, c’est signaler quoi que ce soit pendant la période critique.
Il existe un deuxième contrôle, plus restreint, qu'il est utile de connaître. L'exécution de la commande « npm audit signatures » permet de vérifier les signatures du registre des paquets téléchargés et, le cas échéant, leurs attestations de provenance. Ces contrôles interviennent tous à des moments différents du processus, ce qui est plus facile à visualiser en les comparant côte à côte.
| Catégorie | Ce qu'il capture | Quand elle intervient |
|---|---|---|
| audit npm | Les vulnérabilités connues répertoriées dans les données des avis qu'il analyse | Dès que les données consultatives le couvrent |
| Scanners comportementaux et statiques | Nouveaux paquets suspects, scripts, techniques d'obfuscation | Après la publication, avant ou après votre installation |
| Vérifications des signatures du registre | Des signatures manquantes ou non valides pouvant indiquer une altération | Lorsque les signatures sont vérifiées |
| Contrôles de provenance | Vérification de la concordance entre la provenance déclarée d’un paquet et son processus de compilation, d’une part, et son attestation, d’autre part | Lorsque les attestations sont vérifiées |
| Registres vérifiés et reconstitués | Objets qui ne satisfont pas aux critères de vérification de la provenance ou au contrôle de détection des logiciels malveillants | Avant que votre compilation ne puisse les résoudre |
Outils d'analyse comportementale et statique
Lorsque les données d'audit correspondent aux données de conseil, les outils comportementaux inspectent le paquet lui-même. Ils examinent ce qui a changé d'une version à l'autre : une nouvelle dépendance apparue sans raison apparente, un script d'installation qui n'existait pas dans la version précédente, du code obscurci, des appels réseau que personne n'a demandés.
Ce que cet audit npm ne parvient pas à détecter
Un tout nouveau paquet, ou une version publiée il y a quelques minutes sans qu'aucun avis de sécurité ne l'accompagne, est l'un des cas pour lesquels cet outil a été conçu. Il n'a pas besoin d'un CVE pour signaler un script post-installation suspect qui se connecte à un domaine inconnu, ou une modification qui ajoute des centaines de kilo-octets de code obfusqué dans une bibliothèque de mise en cache sans aucune raison valable. C’est là sa valeur fondamentale : détecter les comportements plutôt que d’attendre que quelqu’un d’autre les répertorie en premier.
Les domaines dans lesquels ils ont encore des lacunes
Ces outils nécessitent un réglage avant que le signal ne justifie une intervention, et les faux positifs alimentent ce phénomène de « fatigue des alertes » qui finit par pousser quelqu’un à désactiver le canal. De plus, ils ne vérifient pas l’origine d’un paquet, mais uniquement ce qu’il semble faire ; ainsi, une charge utile qui reste inactive pendant la fenêtre d’analyse peut tout de même passer entre les mailles du filet.
La plupart d'entre elles comparent également les éléments à ce qui est déjà publié dans le registre, ce qui signifie qu'elles vous signalent un problème une fois que celui-ci s'y est déjà retrouvé. C'est certes une réelle amélioration par rapport à l'attente des données d'alerte, mais cela ne revient pas à décider ce que votre build est autorisé à installer.
Pour avoir une vision plus globale des limites de cette catégorie d'outils, découvrez ce qui fait défaut aux outils de gestion de la chaîne d'approvisionnement.
Vérification de la provenance et de la signature
Les signatures et la provenance apportent des réponses à deux questions auxquelles l'audit ne répond pas : à savoir si l'artefact que vous avez téléchargé se vérifie correctement et où il a été compilé.
Ce que la commande « npm audit » permet réellement de vérifier
Les attestations de provenance npm utilisent Sigstore pour associer un artefact publié au dépôt source et au workflow de compilation qui l'a généré. L'exécution de la commande `npm audit signatures` permet de vérifier que la signature du registre d'un paquet est valide et, lorsqu'une attestation existe, que le paquet comporte une attestation valide le reliant au dépôt source et au workflow de compilation qui y est enregistré.
Pourquoi une signature valide ne garantit pas la sécurité
Il s'agit là de vérifications concrètes et utiles. Une signature de registre non valide peut indiquer qu'un artefact a été altéré, et la traçabilité peut révéler qu'un paquet ne dispose d'aucun historique de compilation ou que son attestation renvoie vers une source différente de celle que vous pensiez obtenir.
Ce que ces deux méthodes ne font pas, c'est évaluer si le code lui-même est sûr. La provenance indique d'où provient un élément, mais pas ce qu'il fait une fois exécuté. Un pipeline qui a été discrètement compromis peut tout de même produire une version dotée d'une attestation tout à fait valide, car celle-ci décrit fidèlement une version réelle d'un code véritablement malveillant. Considérez une vérification de provenance sans anomalie comme un élément parmi d'autres dans une décision de confiance, et non comme une fin en soi.
Registres qui effectuent un filtrage avant la résolution
Cela nous amène à l'aspect que la plupart des équipes pensent avoir déjà pris en compte.
Proxy ou miroir face à un registre qui inspecte et reconstruit
De nombreuses équipes exploitent un registre npm privé servant de proxy ou de miroir devant le registre public, qu’il s’agisse de Verdaccio avec une liaison montante ou d’un référentiel proxy configuré dans Nexus ou Artifactory. Ces produits offrent bien plus que la mise en cache, mais dans cette configuration, leur rôle consiste à servir de point de contrôle pour le trafic sortant et de point unique permettant de déterminer quelles sources sont autorisées. L’inspection n’en fait pas partie. Si aucun élément du chemin ne vérifie l’artefact, un paquet en amont malveillant reste malveillant lorsqu’il est servi à partir de votre cache.
L’autre type de registre intervient sur ce qui transite par lui : il filtre l’artefact, vérifie sa source et, dans certains cas, le recompose à partir de cette source plutôt que de simplement diffuser la dernière version publiée par le registre public. SecureChain de TuxCare, par exemple, recompose les paquets npm à partir de leur source et les filtre avant même qu’ils ne soient disponibles dans son registre. Il s’agit là d’une garantie fondamentalement différente, et c’est précisément ce qui permet de passer du simple contrôle de la provenance des paquets au contrôle de ce qui est réellement installé.
Quels sont les changements lorsqu'un paquet est recompilé à partir du code source ?
La recompilation à partir du code source permet de pallier un mode de défaillance que l'analyse seule ne peut pas détecter, à savoir un artefact publié qui ne correspond pas au contenu réel du dépôt en amont. Si la version utilisée par votre build est recompilée à partir du code source attendu dans un pipeline contrôlé, une archive tar altérée poussée directement dans le registre public à l'aide d'un jeton volé ne pourra pas s'introduire dans ce chemin, tant que le code source lui-même reste intact. Il s’agit d’une garantie plus restreinte que celle selon laquelle « rien de grave ne se produira jamais », mais elle est réelle et vaut indépendamment de la publication ou non d’un avis de sécurité.
Pourquoi l'empilement d'outils entraîne-t-il toujours un décalage temporel ?
Mettez tout cela bout à bout et vous couvrez un large éventail de cas : audit npm pour les vulnérabilités connues, analyse comportementale des nouveaux paquets, vérifications des signatures et de la provenance. Ce que rien de tout cela ne modifie en soi, c'est la liste des artefacts que votre gestionnaire de paquets est autorisé à récupérer au départ.
Les scripts d’installation des dépendances s’exécutaient traditionnellement dès l’installation d’un paquet, souvent avant qu’un scanner n’ait détecté quoi que ce soit et avant qu’un humain ne l’ait examiné. C’est ce qui a rendu l’attaque contre axios si efficace, puisque les versions contenant une porte dérobée intégraient une toute nouvelle dépendance dont le script post-installation exécutait le dropper. Depuis la version 12 de npm, les scripts d’installation des dépendances sont bloqués par défaut, à moins que le projet ne les enregistre dans sa politique allowScripts, ce qui réduit en partie ce risque ; toutefois, les scripts d’installation d’une dépendance compromise peuvent encore être approuvés par erreur.
Si vous ne vous êtes pas encore penché sur le fonctionnement de ce modèle de confiance, le fonctionnement des scripts de cycle de vie et leurs paramètres par défaut actuels sont abordés dans ce guide pratique consacré à l’installation sécurisée des paquets npm. Le blocage des scripts détermine si les scripts d’installation d’une dépendance s’exécutent après que npm l’a sélectionnée et récupérée. Il ne détermine pas si une version malveillante peut être sélectionnée ou non.
C'est cette distinction qu'il convient de garder à l'esprit. Ces vérifications ne modifient pas, en elles-mêmes, la source du paquet à partir de laquelle votre compilation s'effectue ; pour y parvenir, une solution consiste à transférer cette décision vers le registre vers lequel vos compilations pointent.
Combler cette faille avant que l’audit npm ne la détecte
SecureChain n'est pas un substitut à l'audit. Il s'agit d'un registre distinct à partir duquel vos dépendances npm sont résolues. Il remplace le registre public npm par un référentiel sélectionné avec soin et recompilé à partir des sources, qui filtre les paquets avant qu'ils ne soient disponibles à l'installation ; ainsi, ce que votre processus de compilation récupère a déjà fait l'objet d'une vérification des sources et d'un filtrage anti-malware. Pour les équipes qui souhaitent aller au-delà d'une simple détection sous forme d'alerte, cela permet de prendre la décision en amont, là où le délai de notification des alertes a beaucoup moins d'importance.
La couverture s'étend de l'adoption à la mise en œuvre, à l'exploitation et au-delà de la fin de vie du produit ; les paquets actifs sont mis à jour conformément au SLA, et le service « Endless Lifecycle Support » prend le relais dès que la maintenance en amont cesse. Chaque paquet est accompagné d'une traçabilité SLSA de niveau 3, d'une SBOM et de données VEX, sans qu'aucune modification du workflow ne soit nécessaire.
Pour mieux comprendre les risques liés aux dépendances transitives, visionnez le webinaire à la demande ou contactez notre équipe pour en savoir plus sur SecureChain.
FAQ
Quelle est une bonne alternative à npm audit ?
Ce n’est pas une solution à mettre en place directement. npm audit reste toutefois un moyen raisonnable de suivre les avis de sécurité connus dans une arborescence à partir de laquelle vous effectuez déjà vos résolutions. Les options les plus efficaces modifient le moment où la décision est prise, en filtrant les paquets avant que votre processus de compilation ne puisse les récupérer, ce que la mise en correspondance des avis de sécurité ne peut pas faire de par sa conception.
L'outil npm audit détecte-t-il les paquets malveillants ?
Il ne vérifie que les informations contenues dans les avis de sécurité. Les logiciels malveillants font bien l’objet d’avis de sécurité, qui sont intégrés à la base de données GitHub Advisory Database par l’équipe de sécurité de npm et le projet « malicious-packages » de l’OpenSSF ; toutefois, GitHub présente Dependabot, et non audit, comme le canal d’alerte pour ces cas. Quoi qu’il en soit, audit ne peut pas détecter une version malveillante nouvellement publiée en se basant sur son comportement, car il effectue une comparaison avec les données des avis de sécurité plutôt que d’inspecter le paquet lui-même.
Est-il toujours utile d'exécuter npm audit avec un registre filtré ?
C'est surtout une question de visibilité. Un registre filtré et mis à jour en continu modifie la part du travail de correction qui dépend de l'audit, mais son exécution vous permet tout de même de savoir quelles alertes connues concernent les éléments déjà présents dans votre arborescence.
Quelle est la différence concrète entre un registre privé et un registre filtré ?
Un registre privé peut se limiter à n'être qu'un simple proxy ou miroir qui contrôle la provenance des paquets. Un registre filtré inspecte, et dans certains cas recompose, ce qui est effectivement mis à disposition, ce qui constitue une garantie différente et plus solide.
Une vérification de provenance sans problème signifie-t-elle qu'un paquet peut être installé en toute sécurité ?
Non. Une provenance valide relie un artefact à la source et au flux de travail consignés dans son attestation. Elle ne prouve pas que cette source ou ce flux de travail n’aient pas été compromis ; ainsi, un paquet validement attesté peut tout de même être malveillant.
