Comment nuget.org m'a fait totalement changer d'avis sur dependency-check ?
En fin d'année 2023, j'ai publié un retour d'expérience sur dependency-check et son intégration dans Azure DevOps. À l'époque, je ne recommandais pas l'outil pour les développeurs .net. Depuis, les choses ont changé.
Mon article m'a permis d'avoir des retours d'utilisateurs Java.
Petite pause : Oui, dans ce monde de brutes, les développeurs Java, et .net, peuvent échanger sans en venir aux mains.
À ma grande surprise, ceux-ci partageaient le même avis que moi. Je les trouvais même plus critiques (si, c'est possible). Ils mettaient en avant le trop grand nombre de faux positifs. Situation que je commençais aussi à rencontrer.
Des problèmes
Le temps passant, j'ai continué à utiliser dependency-check. Il s'agit d'un outil qui m'est imposé, je n'ai donc pas le choix.
Les problèmes ont continué. La difficulté principale est liée aux API NVD utilisées pour construire la base de données de failles connues (lenteur et indisponibilité). Les solutions recommandées pour fiabiliser cette "base" sont déconcertantes . La "base" est un fichier au format propre à JAVA que l'on pourrait comparer à un SQL local DB. La première solution consiste à planifier un job pour récupérer la "base", et la partager aux serveurs de builds (chargés de la récupérer, et de la décompresser avant chaque utilisation). L'autre consiste en la mise en place d'une vraie base de données, dont il faut gérer soit même le schéma, et effectuer manuellement les mises à jour en appliquant des scripts. Rien de totalement automatisable, ou véritablement DevOps.
On finirait presque par s'habituer à avoir un outil indisponible.
Passé ce stade, mon avis "non recommandé" passe à "presque déconseillé".
Encore des problèmes
Mais les choses ont évolué. L'ami nuget.org est venu plier le game.
Suite aux évolutions de Visual Studio, dotnet.exe, et nuget.org, nous avons des avertissements très visibles quand une librairie contient une faille. Ils étaient déjà visibles quand on utilisait l'interface de gestion des nuages. Maintenant, ils sautent aux yeux dès qu'une compilation est lancée. Il est donc impossible de les ignorer.
Malheureusement, sur les 7 derniers mois, j'ai travaillé sur plusieurs projets qui utilisaient des librairies contenant des failles connues (on parle là de librairies bien établies, pas des projets utilisés par 10 personnes dans le monde). Pour chaque projet, que ce soit via Visual Studio, ou via les pipelines Azure DevOps, j'avais un avertissement lié à nuget.org. Mais dependency-check ne remontait rien. J'ai gardé sous le coude quelques branches non patchées, et 2 mois après, dependency-check ne voyait toujours rien.
Conclusion
Pour moi dependency-check est un produit "fortement déconseillé pour les développeurs .net". Il donne un faux sentiment de sécurité. L'intégration de nuget.org dans Visual Studio et msbuild, est bien plus efficace.