Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Tu cours npm audit, et le voilà :
14 vulnerabilities (3 low, 6 moderate, 4 high, 1 critical)Eh bien, regardez ça : quatorze vulnérabilités. C’est sans doute un projet qui traîne depuis un mois, et auquel vous n’avez peut-être touché que deux fois. Il y a fort à parier que vous ne sauriez même pas citer le nom de ces paquets si on vous le demandait. Ils se sont probablement glissés là par le biais de certaines dépendances directes. La première chose à faire est désormais une routine : lancez npm audit fix, regardez-le résoudre certains des problèmes, fermez le terminal, et reprenez le cours de votre journée. Personne ne se penche vraiment sur l’ensemble des quatorze vulnérabilités.
De la paresse ? Non. De la fatigue ? Oui, et cela mérite d’être considéré comme un problème à part entière plutôt que d’être regroupé sous l’idée que « les développeurs ne se soucient pas de la sécurité », car ces deux situations appellent des solutions très différentes.
Le problème de bruit avec npm audit
npm audit Il a un seul atout : il vous signale qu'une vulnérabilité connue se trouve quelque part dans votre arborescence de dépendances. Quant à savoir si cela a réellement une incidence sur votre application en cours d'exécution, c'est une autre histoire.
Quand du code enfoui à quatre niveaux de profondeur commence à générer une alerte de gravité « Élevée », que devez-vous en faire ? npm définit la gravité en fonction de l’impact et de l’exploitabilité dans le cas d’utilisation le plus courant, mais votre application ne correspond peut-être pas à ce cas de figure. Cela dit, l’argument « on ne l’appelle jamais » n’est pas non plus une excuse valable, car les scripts d’installation et les outils de compilation peuvent exécuter du code vulnérable avant même qu’une requête n’atteigne votre application.
Et puis, il y a le décompte. Ce chiffre de 14 correspond au nombre de paquets signalés, et non à autant de problèmes distincts. Un même paquet peut comporter plusieurs avis de sécurité tout en n’étant compté qu’une seule fois, et npm signale également des « méta-vulnérabilités » : des paquets dont la plage de dépendances déclarée ne peut aboutir qu’à une version affectée d’un élément situé en aval. Ainsi, ces quatorze « vulnérabilités » pourraient en réalité correspondre à quatre ou cinq problèmes distincts se présentant sous différentes formes.
Pire encore, les dépendances de développement sont signalées avec exactement le même niveau d’urgence que le code d’exécution en production. Un plugin ESLint vulnérable sur l’ordinateur portable d’un développeur et une bibliothèque d’authentification vulnérable exposée à l’Internet public ne relèvent fondamentalement pas de la même catégorie d’urgence. Cela va toutefois dans les deux sens. Une dépendance de build qui s’exécute en CI, accède à des secrets ou influence l’artefact que vous déployez n’est pas de faible priorité simplement parce qu’elle se trouve sous devDependencies.
L'outil n'est pas forcément défectueux ; il lui manque simplement le contexte d'exécution nécessaire pour répondre à la question qui vous intéresse.
Pourquoi les équipes perdent-elles leur dynamisme ?
Fatigue, anxiété, nervosité : aucun de ces sentiments n'est propre à la surveillance des dépendances et des flux CVE, mais la sécurité des dépendances est une source majeure de ces trois sentiments.
La pile de tickets semble interminable. Ils s'accumulent plus vite que quiconque ne peut les traiter. Une fois que vous avez évalué votre cinquantième vulnérabilité et que quarante-neuf d'entre elles s'avèrent sans importance, inaccessibles ou déjà traitées ailleurs, la mention « gravité élevée » perd de son poids. C'est ce qu'on appelle la « fatigue des alertes ».
Le véritable coût ne réside pas dans le bruit et les alertes, mais dans ce qui passe inaperçu. Si toutes les alertes sont traitées de la même manière, celles qui comptent vraiment le sont aussi. Les vérifications se transforment alors en simple cochage de cases : les audits s’exécutent dans l’environnement de continuité d’intégration, quelqu’un jette un coup d’œil au nombre d’alertes, mais rien n’est réellement vérifié. Finalement, quelqu’un ajoute || true jusqu’à l’étape d’audit pour que le pipeline repasse au vert, et cette ligne reste là bien après que tout le monde ait oublié pourquoi elle est là. Ce n’est pas que personne ne s’en soucie plus. C’est simplement que le backlog a grossi plus vite que quiconque ne pouvait le résorber.
Les mises à niveau ont elles aussi leur importance. npm audit fix se limite aux mises à jour correspondant aux plages de versions que vous avez définies. Tout ce qui ne relève pas de ces plages, ce qui peut inclure un changement majeur au sens de la norme SemVer, nécessite --force, et la documentation de npm elle-même déconseille de l'utiliser à la légère. Certaines erreurs ne peuvent pas être corrigées automatiquement. « Il suffit de le mettre à jour » n'est pas une réponse aussi simple qu'il n'y paraît.
Un « Triage Pass » plus raisonnable
Cela ne veut pas dire qu'il faille l'ignorer npm audit. Cela signifie qu'il faut cesser de considérer chaque ligne de sortie comme aussi urgente les unes que les autres, car ce n'est pas le cas.
Voici quelques conseils qui s'avèrent vraiment utiles :
- Privilégiez l'accessibilité et l'exposition plutôt que la gravité seule. Une vulnérabilité CVE critique présente dans le code, mais inaccessible dans votre environnement, est généralement moins prioritaire qu'une vulnérabilité modérée directement exposée dans le traitement de vos requêtes. Les niveaux de gravité ne tiennent pas compte de votre graphe d'appels, contrairement à vous.
- Séparez la production du développement, puis vérifiez ce qui fonctionne. Un outil de compilation vulnérable et une dépendance d'exécution vulnérable méritent généralement des délais de réponse différents.
npm audit --omit=devC'est un premier pas utile, mais les outils de développement qui s'exécutent en intégration continue (CI) avec des identifiants, ou le code qu'un bundler intègre dans la version finale, restent essentiels. - Regroupez-les par paquet, et non par CVE. Une seule bibliothèque obsolète peut déclencher plusieurs avis de sécurité.
npm explain <package>indique laquelle de vos dépendances l'a intégrée, ce qui est généralement l'endroit où se trouve la véritable solution. - Définissez un rythme, tout en prévoyant une marge de manœuvre. Effectuez un nouvel audit chaque semaine, ou selon un calendrier adapté à votre cycle de publication, plutôt que de procéder à un nouveau tri à chaque mise à jour du flux. Agissez plus rapidement en cas d’indices d’exploitation active ou d’exposition réelle sur Internet.
- Acceptez que « pas maintenant » soit une réponse valable. Une décision formalisée de reporter le traitement d’un problème à faible risque n’équivaut pas à l’ignorer. Notez pourquoi et quand vous y reviendrez, puis passez à autre chose.
C'est là toute la différence entre le triage et le simple fait de faire le tri dans ses notifications. L'une de ces deux méthodes permet en effet de réduire les risques.
Le rôle de SecureChain
Voici une distinction qu'il convient d'évoquer sans détours : npm audit est de nature consultative. Elle vous indique ce qui ne va pas, et npm audit fix s'occupe des corrections simples, mais les décisions difficiles vous reviennent toujours. C'est à vous de déterminer si une mise à niveau est justifiée et sûre, si un correctif doit être rétroporté, ou si un paquet en fin de vie (EOL) fait l'objet d'une correction en amont.
SecureChain agit en amont de ce problème au lieu d’alourdir la pile des alertes. Le registre public met à disposition tout archive tar publiée par un responsable de maintenance. Les signatures du registre indiquent qu’elle n’a pas été modifiée depuis, mais à moins que le paquet ne soit accompagné d’un certificat de provenance, rien ne permet de le relier au dépôt source. SecureChain recompose les paquets à partir de sources vérifiées dans des environnements sécurisés et isolés, puis les analyse à la recherche de logiciels malveillants et de code suspect avant qu’ils n’atteignent votre arborescence de dépendances. npm audit n'est pas conçu pour détecter à lui seul les « typosquats », les comptes de responsables détournés ou les scripts d'installation malveillants ; il se contente de signaler ce qui figure déjà dans les avis de sécurité. Les correctifs respectent les délais de réponse cibles publiés, que le développeur en amont continue de fournir des correctifs ou qu'il ait cessé toute activité, et dès lors qu'un paquet n'a pas fait l'objet d'une nouvelle version en amont depuis plusieurs mois, Support illimité du cycle de vie propose régulièrement des correctifs pour la version que vous utilisez déjà.
Rien de tout cela ne fait disparaître le triage. Ce qui change, c’est le niveau d’incertitude dont vous héritez avant qu’un paquet n’atteigne votre processus de compilation. Les paquets sont compilés et signés pour prendre en charge le niveau 3 du SLSA, et ils sont accompagnés de données VEX et, selon le paquet, de SBOM. C’est la partie que personne ne souhaite créer manuellement, mais dont la plupart des équipes ont finalement besoin pour un audit. VEX répond le plus directement au problème du « bruit », puisqu’il précise quelles vulnérabilités CVE connues affectent réellement une version spécifique d’un paquet.
Ce qu’il faut retenir ici, c’est que SecureChain n’est pas un flux de plus qui vient solliciter votre attention. Cela signifie qu’il y a moins de messages qui arrivent dans votre file d’attente, car une grande partie du problème a été traitée avant même qu’il ne devienne le vôtre.
