Vérifier l'impact réel plutôt que la présence

La méthode, en trois vérifications

Dans l'ordre, elles suffisent à transformer une alerte brute en verdict fiable :

1. Le code vulnérable est-il importé quelque part ? Une recherche du nom du paquet ou de la fonction concernée dans le code source répond souvent à elle seule à la question.
2. Ce chemin de code est-il atteint en production ? Une dépendance peut être importée uniquement dans un script de build, un test, ou un outil de développement — jamais dans le code qui tourne réellement pour l'utilisateur.
3. Le paquet est-il direct ou transitif — et à quelle profondeur ? Une dépendance transitive de dépendance de dépendance de build est un signal beaucoup plus faible qu'une dépendance directe de production.

Exemple

# Le paquet apparaît-il vraiment dans l'usage du code applicatif ?
grep -rn "nom-du-paquet" src/ --include="*.ts" --include="*.tsx"

# À quoi ressemble sa chaîne de dépendance ?
pnpm why nom-du-paquet

Si la recherche ne remonte rien dans src/, et que pnpm why montre que le paquet n'arrive que via un outil de build jamais exécuté en production, le verdict est clair : présent, mais non exposé.

Le verdict final

À l'issue de cette vérification, chaque CVE de la liste initiale reçoit un verdict binaire simple : exposé ou non exposé. Seules les CVE "exposées" méritent qu'on passe au module suivant — évaluer un correctif.