CVE Lite CLI : je l'ai testé sur un projet vulnérable - Mehdi Rahmani

CVE Lite CLI est un scanner de vulnérabilités pour dépendances JavaScript et TypeScript qui part du lockfile local, interroge OSV, puis propose un plan de correction. Après un vrai test sur un petit projet volontairement vulnérable, mon avis est simple : ça vaut le coup de l’essayer si vous voulez un retour rapide dans le terminal, sans compte SaaS et sans pipeline lourd.

CVE Lite CLI, c’est quoi ?

CVE Lite CLI est un outil OWASP Incubator qui scanne les dépendances npm, pnpm, Yarn et Bun. Son angle n’est pas seulement de lister des CVE, mais de répondre à la vraie question du développeur : qu’est-ce que je dois mettre à jour maintenant ?

Il lit le lockfile, interroge la base OSV, distingue les dépendances directes des transitives, puis génère des commandes de correction. Il peut aussi produire un rapport HTML, du JSON, du SARIF pour GitHub Code Scanning et lancer un mode de correction automatique.

Point testé	Résultat observé
Version testée	1.23.0 depuis le dépôt GitHub
Runtime	Node.js 20.20.2
Installation	`npm ci`, build TypeScript, test suite complète
Tests projet	36 suites Jest, 485 tests passés
Cas d’usage	Projet npm avec `lodash`, `minimist`, `ws`, `serialize-javascript` vulnérables
Sorties	Terminal, JSON, SARIF, rapport HTML, mode fix

Installation de CVE Lite CLI

La voie normale est très simple :

npm install -g cve-lite-cli
cve-lite /chemin/vers/projet

Pour ce test, j’ai volontairement cloné le dépôt et lancé le produit depuis les sources :

git clone https://github.com/OWASP/cve-lite-cli /tmp/cve-lite-cli
cd /tmp/cve-lite-cli
npm ci
npm run build
npm test -- --runInBand

Dans mon conteneur, l’installation directe dans /tmp a d’abord échoué sur un postinstall npm avec Permission denied, classique quand /tmp est monté avec des restrictions d’exécution. J’ai donc gardé le clone en /tmp pour l’inspection, puis lancé l’installation dans un dossier temporaire exécutable et supprimé à la fin. Le build est passé, et la suite de tests a donné 36 suites et 485 tests au vert.

CVE Lite CLI à l’usage

J’ai créé un petit projet npm avec quatre dépendances connues pour déclencher des alertes :

npm init -y
npm install lodash@4.17.20 minimist@0.0.8 ws@7.4.5 serialize-javascript@2.1.1 --package-lock-only

J’ai aussi ajouté un fichier src/index.js qui importe lodash, minimist et ws, mais pas serialize-javascript. L’idée était de voir si l’option d’analyse d’usage faisait bien ressortir la différence entre paquet importé et paquet seulement présent dans le lockfile.

Commande principale :

cve-lite . --verbose --all --report ./cve-report --no-open --usage --no-cache

Résultat : CVE Lite CLI a parsé 4 paquets depuis package-lock.json, trouvé 4 paquets vulnérables et 11 CVE au total. Le résumé affichait 1 critique et 3 hautes, avec des commandes npm prêtes à copier.

Ce que j’ai apprécié : la sortie ne s’arrête pas à une table de CVE. Elle groupe les corrections par sévérité, affiche la version actuelle, la cible, le nombre de versions testées, et indique si le paquet est utilisé dans le code. Dans mon test, serialize-javascript était correctement marqué comme unused, pendant que lodash, minimist et ws étaient liés à src/index.js.

Le rapport HTML est aussi utile. Il donne une vue exploitable pour une revue avec un lead dev ou un client : compteurs par sévérité, commandes de fix, table filtrable, détails des vulnérabilités.

J’ai ensuite lancé les sorties machine :

cve-lite . --json
cve-lite . --sarif

Le JSON a confirmé les chiffres : packageCount: 4, findingCount: 4, et une commande agrégée npm install minimist@0.2.4 lodash@4.18.0 serialize-javascript@7.0.3 ws@7.5.10. Le SARIF a été écrit dans un fichier .sarif, prêt pour une intégration GitHub Code Scanning.

CVE Lite CLI avec le mode fix, ça donne quoi ?

J’ai testé le mode fix sur une copie du projet pour ne pas mélanger observation et correction :

cve-lite . --fix --verbose --no-cache

Le mode fix a modifié package.json et package-lock.json, puis a rescanné. Il a annoncé 4 corrections appliquées : minimist vers 0.2.4, lodash vers 4.18.0, serialize-javascript vers 7.0.3, et ws vers 7.5.10.

Après correction, le scan ne remontait plus qu’une vulnérabilité moyenne sur serialize-javascript@7.0.3, avec une proposition de passage en 7.0.5.

Mon interprétation : le mode fix accélère le nettoyage, mais je ne le lancerais pas en aveugle sur un repo client. Je l’utiliserais sur une branche dédiée, avec tests applicatifs derrière.

Ce que j’aime dans CVE Lite CLI

Le gros point fort, c’est la lisibilité. En prestation sécu ou DevOps, le problème n’est pas seulement de savoir qu’une dépendance est vulnérable. Le vrai problème est de transformer ça en action sans perdre une demi journée dans des tickets et des dashboards.

J’aime particulièrement :

la lecture locale du lockfile, sans compte obligatoire ;
le support npm, pnpm, Yarn et Bun ;
la séparation direct et transitif ;
les commandes de correction prêtes à lancer ;
le rapport HTML partageable ;
le JSON et le SARIF pour automatiser ;
l’analyse d’usage, pratique pour prioriser ce qui est réellement importé.

Les limites de CVE Lite CLI

CVE Lite CLI ne prouve pas qu’une vulnérabilité est exploitable dans votre application. L’outil le dit lui-même dans ses notes de couverture : il vérifie des versions de dépendances face à OSV, pas le comportement runtime complet.

Quelques limites à garder en tête :

il ne scanne pas les images conteneur, les binaires, les secrets ou l’IaC ;
node_modules n’est pas vérifié dans le scan, le lockfile reste la source de vérité ;
les workspaces monorepo sont annoncés comme partiellement modélisés dans cette version ;
le mode fix doit être suivi par vos tests, surtout en cas de saut de version majeur ;
la qualité des résultats dépend aussi des données OSV.

J’ai aussi noté que les formats ne sont pas tous combinables : le rapport HTML, le JSON et le SARIF demandent des runs séparés. Ce n’est pas grave, mais il faut le savoir pour écrire un script CI propre.

Est-ce que CVE Lite CLI marche vraiment ?

Oui, sur mon test concret, ça marche. Le scanner a trouvé les paquets vulnérables attendus, a identifié les dépendances utilisées dans le code, a produit un rapport HTML, un JSON, un SARIF, et le mode fix a réellement modifié les fichiers npm.

Le point important : il ne remplace pas une politique de patch management. Il accélère la première passe. Pour un freelance, une petite équipe ou un projet open source, c’est déjà beaucoup.

Je le vois très bien dans trois usages :

avant de pousser une branche, pour éviter les surprises ;
dans une CI légère, avec un seuil de sévérité ou SARIF ;
en audit rapide, pour transformer un lockfile en plan de correction compréhensible.

Faut-il adopter CVE Lite CLI ?

Mon verdict : essayer, puis adopter sur les projets JavaScript où vous voulez une boucle courte de remédiation.

Je ne le vendrais pas comme une plateforme de supply chain security complète. Ce n’est pas Snyk, Socket ou une console CNAPP. En revanche, comme outil local, gratuit, lisible, orienté développeur, CVE Lite CLI coche beaucoup de cases.

Si vous maintenez des projets JS ou TS, le coût d’essai est faible, et le gain de clarté est réel.

FAQ

CVE Lite CLI envoie-t-il mon code dans le cloud ?

Non, dans le fonctionnement testé, il lit le lockfile local et interroge OSV pour les advisories. Il ne fait pas une analyse complète du code source côté serveur.

CVE Lite CLI remplace-t-il npm audit ?

Pas forcément. Je le vois plutôt comme un complément plus lisible, surtout pour les commandes de correction, le rapport HTML, le SARIF et la distinction direct ou transitif.

Peut-on utiliser CVE Lite CLI en CI ?

Oui. Les sorties JSON et SARIF sont adaptées à l’automatisation, et un seuil de sévérité peut faire échouer une pipeline. Il faut simplement lancer les formats séparément si vous voulez aussi générer un rapport HTML.

CVE Lite CLI : je l’ai testé sur un projet vulnérable