Alors que les assistants de codage basés sur l'IA accélèrent le développement logiciel, un projet open source soutenu par l'Open worldwide application security project (Owasp) fait valoir que les outils de sécurité des dépendances arrivent encore trop tard pour être vraiment utiles. CVE Lite CLI, un scanner de vulnérabilités des dépendances JavaScript et TypeScript axé sur l'analyse locale des lockfiles, s'articule autour d'une idée simple. Les développeurs devraient identifier les risques liés aux dépendances pendant qu'ils écrivent encore le code, et non plusieurs heures plus tard au sein d'un pipeline d'intégration continue défaillant. « Ce qui manque aux développeurs, c'est un retour d'information précoce au moment où ils doivent prendre leurs décisions sur les dépendances », a déclaré Sonu Kapoor, créateur et responsable du projet. Selon M. Kapoor, les workflows traditionnels centrés sur l'intégration continue (CI) coupent souvent les développeurs des choix de dépendances qui ont introduit le risque en premier lieu.

CVE Lite CLI analyse les lockfiles npm, pnpm et Yarn à l’aide de la base de données d'informations sur les vulnérabilités des logiciels open source OSV (open source vulnerability) de Google en se concentrant fortement sur les conseils de correction, en distinguant notamment les vulnérabilités directes et transitives, en validant les cibles de mise à niveau et en recommandant des pistes de correction concrètes. Le projet est présenté comme un outil de développement « axé sur l'environnement local », et non comme un substitut aux plateformes d'analyse de la composition des logiciels (Software Composition Analysis, SCA) d'entreprise, à l'instar de ESLint ou des tests unitaires en local déjà utilisés par les développeurs avant que l'intégration continue (CI) ne les exécute à nouveau ultérieurement.

Un problème de workflow souvent négligé

Selon M. Kapoor, CVE Lite CLI tente essentiellement de résoudre un problème de workflow avec lequel se débattent discrètement de nombreux développeurs. Les vérifications de sécurité des dépendances interviennent souvent une fois le travail déjà terminé. L'outil analyse localement les lockfiles JavaScript et TypeScript dans les projets npm, pnpm et Yarn, afin que les développeurs puissent comprendre les risques liés aux dépendances pendant qu'ils codent, et non plus tard, en réaction à un pipeline d'intégration continue défaillant. Au lieu de se concentrer uniquement sur la détection, l’outil prétend examiner des questions connexes, par exemple la nature directe ou transitive du problème, l’existence d’un chemin de mise à niveau propre, ou la capacité d’une mise à niveau d’un paquet à supprimer effectivement la dépendance vulnérable. « Dans un cas concret, CVE Lite CLI a ignoré 27 versions de paquets avant de trouver une version plus sûre à recommander », a souligné M. Kapoor, en expliquant la granularité de l’outil. « C'est le genre de travail que les développeurs ne devraient pas avoir à effectuer manuellement en lisant les journaux et en réessayant les mises à jour une par une. » M. Kapoor a indiqué que l'outil peut être configuré pour des sorties JSON, SARIF ou HTML et il peut également être intégré dans les workflows de CI en tant qu'action GitHub.

L'IA pourrait aggraver la situation

Ce débat intervient alors que la sécurité du cycle de développement logiciel continue de se heurter aux pratiques de codage assisté par l'IA, qui permettent aux développeurs de générer du code, d'intégrer des paquets et de restructurer des projets bien plus rapidement qu'auparavant. Selon M. Kapoor, cette rapidité modifie la nature même du risque lié aux dépendances. « Les assistants IA de codage ont renforcé ce risque plus qu’ils ne l’ont atténué », a-t-il affirmé. « Cette rapidité est utile, mais elle implique également que les décisions relatives aux dépendances peuvent être prises rapidement et parfois sans bénéficier du même niveau de vérification manuelle », a-t-il poursuivi. « Je ne pense pas que les assistants IA rendent les contrôles de sécurité superflus. Au contraire, ils renforcent la nécessité de contrôles rapides, locaux et explicables, pouvant être exécutés pendant que le travail est en cours », a-t-il ajouté.

Un exemple cité concernait des analyses effectuées sur lint-staged, un paquet d’outils JavaScript largement utilisé. Selon M. Kapoor, un workflow standard « npm audit –omit=dev » n’a pas permis de mettre en évidence un problème de dépendance en production que CVE Lite CLI a ensuite identifié grâce à l’analyse des fichiers de verrouillage. « Honnêtement, je ne pense pas que la plupart des développeurs comprennent ces angles morts en détail, et je ne dis pas cela pour les critiquer », a-t-il estimé. « Le graphe de dépendances dans un projet JavaScript moderne est extrêmement bruyant. » Un développeur qui souhaite installer une seule dépendance directe peut se retrouver avec des centaines, voire des milliers de paquets transitifs.

Un usage modéré de l'IA

Malgré la pression croissante du secteur pour regrouper les outils de sécurité au sein d’un écosystème basé sur l’IA, le projet évite aussi délibérément de se transformer en plateforme AppSec plus générale. « Je pense effectivement que les outils de sécurité sont devenus trop lourds pour le workflow quotidien des développeurs », a estimé M. Kapoor. « Cela ne signifie pas que ces plateformes sont mauvaises, mais simplement qu’elles répondent souvent mieux aux besoins des équipes de sécurité qu’à ceux du développeur individuel qui cherche à prendre une décision sûre concernant les dépendances lors d’une session de codage normale. » Cette philosophie s’étend également à l’approche du projet par rapport à l’IA elle-même. Alors que CVE Lite CLI inclut des intégrations qui aident les assistants IA de codage à interpréter les résultats d’analyse, M. Kapoor a précisé que l’analyse des vulnérabilités sous-jacente restait intentionnellement déterministe. « Je ne pense pas que l’IA doive décider si un CVE existe », a-t-il déclaré. « Cette partie doit être ennuyeuse, reproductible et vérifiable. » Au lieu de cela, le projet utilise l’IA comme une « couche d’explication et de workflow », selon la présentation qu’en fait le fondateur, autour des résultats d’analyse plutôt que comme scanner lui-même. « CVE Lite CLI intègre des compétences d’assistant IA qui enseignent à des outils comme Claude Code, Codex CLI, Gemini CLI, Cursor et GitHub Copilot comment exécuter CVE Lite CLI, lire sa sortie structurée et aider le développeur à comprendre ou à hiérarchiser le plan de correction », a expliqué M. Kapoor.

Prudence face à l’expansion

Selon M. Kapoor, les retours de la part des entreprises et des développeurs qui utilisent CVE Lite CLI dans leurs flux de travail réels sont positifs et ils se demandent si la même approche pourrait s'appliquer aux écosystèmes .NET ou Python. « Cet intérêt est encourageant, car il montre que le modèle axé sur la correction et privilégiant le local trouve un écho au-delà du cas d’usage initial de JavaScript et TypeScript », s’est-il félicité. « Mais je reste prudent quant à une extension trop large de l'outil actuel. » En effet, selon lui, chaque écosystème possède son propre comportement de gestionnaire de paquets, son format lockfile, sa sémantique de graphe de dépendances, ses sources d’avis de sécurité et ses modèles de correction. « Les intégrer directement dans CVE Lite CLI risquerait d’alourdir l’outil et de le rendre moins clair pour les développeurs JavaScript et TypeScript qu’il était initialement destiné à aider. » Le projet a désormais été intégré à l’écosystème de la fondation OWASP en tant que projet officiel de l’Owasp et il est disponible gratuitement pour les développeurs sur GitHub.