TL; DR
Trouver les vulnérabilités des packages npm est facile. npm audit Elle le fait en quatre secondes et vous fournit 400 résultats. La difficulté réside dans les deux questions suivantes : lesquelles sont réellement accessibles dans votre application, et quelle mise à jour corrige le problème sans perturber la compilation ?
- La majeure partie de cette liste ne concerne pas votre problème. L'application des critères d'accessibilité et du contexte d'exécution aux résultats « critiques » ne laisse subsister qu'une petite fraction de résultats critiques. L'analyse du graphe d'appels permet de les identifier.
npm audit fix --forcen'est pas une stratégie de résolution de problèmes. Il résout les problèmes en sautant des versions majeures, ce qui transforme une tâche de sécurité en panne.- C'est au niveau des dépendances transitives que réside le volume. Vous ne les avez pas choisis, vous ne pouvez souvent pas les améliorer directement, et ils dominent le nombre de découvertes.
- Corrigez avant la fusion, pas après la publication. Une porte dans l'intégration continue et un système automatisé pull request Cela coûte quelques minutes. Un correctif de production coûte un week-end.
Pourquoi le nombre de résultats n'est pas le problème
Chaque projet Node, après sa première année, offre la même expérience : vous lancez une analyse, vous découvrez des centaines de vulnérabilités dans les packages npm, et la liste est tellement longue que la réaction logique est de fermer le terminal.
Cette réaction est justifiée, et c'est là le problème. Près des trois quarts des bases de code contiennent des composants open source à haut risque, et la plupart des éléments signalés par un scanner sont effectivement présents dans votre arborescence de dépendances. La liste est exacte. Simplement, elle ne constitue pas une file d'attente de tâches.
Ce qui fait la différence entre une liste précise et une liste exploitable, c'est le contexte, et cela se résume à quelques questions.
- Le code vulnérable est-il réellement accessible depuis mon application ?
- Est-ce que quelqu'un exploite cela en conditions réelles ?
- Ce que cela affecte a-t-il une importance pour l'entreprise ?
Un scanner qui ne peut pas répondre à ces questions vous remet un inventaire et l'appelle un rapport.
Comment vérifier les vulnérabilités des packages npm
Il existe quatre méthodes pratiques pour vérifier les vulnérabilités des packages npm, et elles répondent à des questions différentes.
Préparer : npm audit Parce que c'est gratuit et ça prend quelques secondes. Mais n'en restez pas là, car la réponse est « voici tout », et « tout » n'est pas un plan.
Un point important à savoir si vous utilisez les flux d'avis de sécurité : la base de données d'avis de sécurité GitHub contient des avis de sécurité concernant les logiciels malveillants dans l'écosystème npm, mais Dependabot choisit délibérément de ne pas les signaler, car un utilisateur en aval ne peut généralement pas les résoudre par une simple mise à jour. Il s'agit d'une lacune structurelle, et non d'un paramètre modifiable. Les paquets malveillants nécessitent un contrôle différent : une détection dès leur publication plutôt qu'après leur divulgation. Alerte précoce contre les logiciels malveillants Il analyse les nouveaux packages publiés sur npm, PyPI, Maven et autres registres dès leur apparition, en utilisant l'analyse comportementale et la détection d'anomalies plutôt que d'attendre une signature. Cette fonctionnalité est incluse dans le forfait Développeur gratuit. Nous l'abordons dans [référence manquante]. malveillant packages npm.
Les filtres qui transforment 400 résultats en une liste restreinte
C'est cet élément qui change la façon dont une équipe fonctionne.
| Filtre | La question à laquelle elle répond | Ce qu'il supprime généralement |
|---|---|---|
| Atteint | L'exécution de mon application peut-elle réellement atteindre la fonction vulnérable ? | La plus grosse réduction. La plupart des avis se trouvent dans du code que l'application n'appelle jamais. |
| Exploitation de la disponibilité | Existe-t-il une faille exploitable publiquement et est-elle actuellement exploitée ? | Permet de distinguer le risque théorique du risque exploité. Une découverte faisant état d'une faille de sécurité publique est traitée en priorité, quel que soit son score de gravité. |
| Probabilité d'exploitation (EPSS) | Quelle est la probabilité d'exploitation à l'état sauvage au cours des 30 prochains jours ? | Des constats graves que personne n'exploite, qui sont rarement au programme cette semaine. |
| Contexte d'affaires | Le service concerné a-t-il une importance, et est-il exposé ? | Des résultats accessibles et exploitables dans des systèmes qui ne comportent aucun risque significatif |
| Disponibilité des correctifs | Existe-t-il une version qui résout ce problème sans me causer de problèmes ? | Permet de distinguer ce que vous pouvez fermer aujourd'hui de ce qui nécessite une solution de contournement. |
- Atteint Il s'agit de la première et de la plus importante réduction. Une vulnérabilité dans un paquet dont vous dépendez n'est exploitable que si l'exécution peut effectivement atteindre la fonction vulnérable. Le traçage du graphe d'appels répond à cette question au niveau de la fonction plutôt que de se baser sur le manifeste, et il distingue les composants que vous utilisez réellement de ceux qui sont simplement présents. L'analyse d'accessibilité de Xygeni réduit les faux positifs jusqu'à 70 %.
Exploitation de la disponibilité Il s'agit de la seconde, et c'est un fait avéré plutôt qu'une prévision. Une exploitation publique active, ou une exploitation confirmée en conditions réelles, modifie la priorité d'une découverte, indépendamment de son score de gravité. Cette distinction n'est plus une simple bonne pratique, mais une obligation : en vertu de la loi sur la cyber-résilience, un fabricant qui découvre une vulnérabilité activement exploitée dans son produit est tenu de la signaler dans les 24 heures. Un programme incapable de faire la distinction entre « exploitation active » et « score CVSS élevé » ne peut respecter ce délai.
La probabilité d'exploitation est le troisième critère, et il s'agit de la même question, à laquelle on réintègre la prédiction. Le score EPSS évalue la probabilité qu'une vulnérabilité soit exploitée en conditions réelles dans les 30 prochains jours, ce qui est très différent de l'ampleur des dégâts qu'elle pourrait causer. Un score CVSS élevé associé à un score EPSS négligeable est rarement le résultat escompté cette semaine.
- Contexte d'affaires Il s'agit de la troisième, et c'est la seule qu'aucun flux générique ne peut fournir. Une vulnérabilité accessible et exploitable dans un service de paiement en ligne est différente de la même découverte (CVE) dans un outil de reporting interne.
Appliqués conjointement, ces filtres transforment systématiquement une liste que personne ne consulte en une liste que quelqu'un consulte. Le contexte d'exécution et d'accessibilité ne laisse généralement subsister qu'une petite minorité de résultats « critiques » qui le restent. Xygeni considère l'accessibilité, la disponibilité des exploits, l'EPSS et le contexte métier comme des étapes configurables d'un entonnoir de priorisation, jusqu'à huit. Ainsi, les éléments « accessibles et activement exploités » deviennent une file d'attente permanente plutôt qu'une requête exécutée manuellement.
Correction des vulnérabilités des packages npm sans perturber la compilation
Trouver les failles est la partie la plus facile. Si les vulnérabilités des packages npm restent non résolues pendant des mois, c'est parce que les corriger comporte des risques, et les développeurs en sont conscients.
Avant toute mise à jour, la question essentielle n'est pas de savoir si cette version corrige la CVE, mais plutôt trois : quelles vulnérabilités disparaissent, quelles nouvelles apparaissent et le changement de version risque-t-il de rendre mon code incompatible ?
Xygéni Il affiche les trois options pour chaque dépendance vulnérable, ce qui permet de choisir entre des options visibles plutôt que de faire un choix éclairé. Ensuite, Autofix génère le pull request Avec la version corrigée, la correction en masse applique plusieurs correctifs en une seule action, et le bot Xygeni s'exécute à la demande. pull requests ou quotidiennement, de sorte que le nombre de tâches en attente diminue sans que personne ne le planifie.
Pour les dépendances transitives, où vous ne pouvez pas simplement passer à une version que vous n'avez pas choisie, le résultat utile est le chemin de mise à niveau le plus court dans l'arborescence qui résout l'avis, et non une alerte vous indiquant qu'un paquet quatre niveaux plus bas est vulnérable.
Avant l'expédition : Où doit être envoyé le chèque
« Avant leur expédition » est une revendication de planification, et cela se résume à trois placements.
- Dans l'IDEAinsi, un développeur repère le problème au moment de choisir la dépendance, ce qui représente le moment le plus économique pour la modifier.
- Sur le pull requestDans ce système, un bot commente les modifications apportées et ouvre le correctif, tandis qu'un contrôle de sécurité peut bloquer une compilation en cas de résultats dépassant un certain seuil. Le fait de se baser uniquement sur la gravité des anomalies incite les équipes à désactiver le contrôle. En revanche, le fait de se baser sur la vulnérabilité et l'exploitabilité des anomalies les encourage à le conserver.
- Continuer après la libération, En effet, une dépendance saine lors de la fusion devient vulnérable dès la publication d'un avis de sécurité. La surveillance continue des registres permet de détecter ce problème, sans qu'il soit nécessaire de relancer une analyse.
Et le résultat de ces trois opérations doit être placé dans une file d'attente priorisée avec votre SAST, secrets et découvertes de conteneurs, y compris celles ingérées par les outils que vous utilisez déjà. A liste des vulnérabilités Cette liste, qui vit dans sa propre console, rivalise d'attention avec le travail qu'elle était censée informer.
Expédiez la solution, pas la découverte.
Un scanner qui vous signale 400 vulnérabilités de packages npm n'a pas fait le travail. Il l'a simplement déplacé.
Xygeni affine les résultats de dépendance en fonction de l'accessibilité, de la probabilité d'exploitation et du contexte métier, indique ce que chaque mise à jour corrige et ce qu'elle risque de casser, et ouvre le pull request avec la version patchée. Elle s'exécute dans votre pipeline, produit SBOM et les résultats VDR dans SPDX et CycloneDX, les preuves demandées par CRA, NIS2 et DORA, et placent les résultats de dépendance dans la même file d'attente prioritaire que le reste de votre risque, y compris les résultats des scanners que vous ne remplacez pas.
Commencer gratuitement et analyser un dépôt, ou voyez comment l'accessibilité modifie la liste.
QFP
Comment vérifier si les paquets npm présentent des vulnérabilités ?
Courir npm audit Pour un aperçu rapide, utilisez un outil d'analyse d'accessibilité afin de restreindre la liste aux résultats où le code vulnérable peut être exécuté. Les bases de données d'avis de sécurité comme OSV et la base de données d'avis de sécurité GitHub sont utiles pour vérifier un paquet et une version spécifiques.
Is npm audit fix Peut-on l'utiliser sans risque ?
La version non forcée est généralement sûre, car elle reste dans les plages compatibles semver. npm audit fix --force Non : il effectue des mises à niveau entre les versions majeures pour corriger les problèmes signalés, et c’est de là que proviennent les changements incompatibles.
Pourquoi ai-je autant de vulnérabilités dans mes packages npm ?
Parce que la plupart sont transitives. On installe quelques dépendances directes et on hérite de centaines de dépendances indirectes, chacune avec son propre historique de recommandations. Le volume est normal. C'est le triage qui fait défaut.
Qu'est-ce que l'analyse d'accessibilité ?
Il s'agit de déterminer si l'exécution de votre application peut effectivement atteindre la fonction vulnérable d'une dépendance. C'est le moyen le plus efficace de réduire le bruit en matière de sécurité des dépendances, car la plupart des vulnérabilités signalées se trouvent dans du code que votre application n'appelle jamais.
Dois-je utiliser CVSS ou EPSS pour la priorisation ?
Les deux, mais pour des raisons différentes. CVSS décrit la gravité d'une vulnérabilité si elle était exploitée. EPSS estime la probabilité d'exploitation dans les 30 prochains jours. La gravité sans la probabilité conduit à un classement erroné.
À quelle fréquence dois-je vérifier les paquets npm pour détecter les vulnérabilités ?
En continu, sans horaire fixe. Un scan normal le lundi n'a aucune incidence le mercredi si une alerte est émise concernant un colis déjà expédié.
