Dépendances avec des CVE connues
Un outil qui trouve juste « lodash est dépassé » n'est pas très actionnable. Vetora colle le package-lock.json que tu fournis contre OSV.dev (la base de vulnérabilités ouverte de Google/OpenSSF, qui agrège GitHub Security Advisories et NVD), puis enrichit chaque correspondance avec trois informations concrètes.
Ce que chaque finding contient
- Le CVE (ou l'identifiant GHSA à défaut) et un résumé de la faille.
- Le score CVSS, calculé à partir du vecteur officiel (ex.
CVSS:3.1/AV:N/AC:L/...) — pas juste un label « élevé » vague. - La version corrigée exacte à installer.
- Si le CVE figure au catalogue CISA KEV — c'est-à-dire exploité activement dans la nature, pas seulement théoriquement exploitable.
- Le score EPSS — la probabilité estimée que cette faille précise soit exploitée dans les 30 prochains jours.
Portée actuelle
Pas un scanner universel, mais pas limité à un seul écosystème non plus — largement suffisant pour cibler les apps générées par Bolt, Lovable, v0 ou Cursor, qui s'appuient parfois sur un backend Python ou PHP en plus du frontend Node.js. Cinq formats sont lus : package-lock.json (npm, lockfileVersion 2/3), yarn.lock (classic v1 et Berry), pnpm-lock.yaml, requirements.txt (Python — uniquement les paquets épinglés avec ==, une plage de versions n'a pas de version résolue unique à interroger) et composer.lock (PHP). Maven (Java) et Go ne sont pas encore supportés.
Le correctif
Dans l'immense majorité des cas : mets à jour le package vers la version corrigée indiquée. S'il n'y en a pas encore, évalue le risque réel (le code vulnérable est-il seulement atteignable ?) avant de considérer un remplacement.
Vérifie si ton site est concerné par cette faille.
Scanner mon app