Annonce des correctifs automatisés pour les vulnérabilités des dépendances .NET

Nous sommes ravis d’annoncer une prise en charge améliorée des applications .NET dans Snyk Open Source, qui permet aux développeurs de corriger les vulnérabilités des dépendances .NET grâce à des conseils concrets et à des pull requests automatisées !

À la date de rédaction de cet article, NuGet, le gestionnaire de packages .NET pris en charge par Microsoft et devenu la norme de facto, compte 276 266 packages uniques, téléchargés en moyenne plus d’un milliard de fois par semaine ! En 2020, juste après npm, NuGet a enregistré la plus forte croissance annuelle en nombre de packages ajoutés.

Ces chiffres témoignent de la popularité du framework .NET, mais aussi de l’un des principaux défis auxquels sont confrontées les équipes de développement .NET : gérer et atténuer les risques de sécurité liés aux vulnérabilités connues dans ces packages. Souvent, ces vulnérabilités se trouvent dans des dépendances transitives, c’est-à-dire des packages intégrés par d’autres packages. Elles sont donc plus difficiles à repérer, et leur correction se complique.

Les nouvelles fonctionnalités de Snyk Open Source permettent aux développeurs non seulement de détecter avec précision les vulnérabilités dans leurs dépendances .NET directes et transitives, mais aussi de les corriger automatiquement.

Sécurité .NET avec Snyk Open Source

Dans Snyk Open Source, l’identification et la correction des vulnérabilités des dépendances .NET s’appuient sur deux processus clés : l’analyse précise de l’arborescence des dépendances, puis la mise en correspondance avec Snyk Intel, la base de données de vulnérabilités de référence de Snyk.

Analyse des dépendances

Dans l’écosystème .NET, les dépendances comportent plusieurs niveaux : certaines sont évidentes, tandis que d’autres sont totalement invisibles pour les développeurs.

Pour identifier correctement les vulnérabilités d’une application .NET donnée, il faut résoudre ces dépendances avec précision.

La résolution des dépendances diffère dans Snyk CLI et dans les systèmes de gestion du code source (SCM), par exemple Azure Repos, GitHub, etc. Dans Snyk CLI, par exemple, selon la manière dont vous gérez les dépendances de votre projet — avec PackageReference ou packages.config, par exemple — nous analysons votre fichier obj/project.assets.json dans le premier cas et le répertoire des packages dans le second. Cette approche nous permet d’obtenir des résultats très précis.

L’analyse des projets via l’intégration SCM nécessite un processus différent, car les fichiers générés mentionnés ci-dessus ne sont pas disponibles. Pour contourner cette limite, nous suivons l’algorithme de résolution des dépendances de NuGet afin de construire une arborescence des dépendances. À noter : les dépendances d’exécution (fournies par l’environnement, c’est-à-dire les métapackages) sont résolues avec davantage de précision dans Snyk CLI si la machine hôte utilise un SDK d’exécution similaire à celui du serveur exécutant l’application.

Renseignements sur les vulnérabilités

Une fois l’arborescence des dépendances établie, Snyk Open Source met la liste des dépendances en correspondance avec Snyk Intel. Avec une liste complète de vulnérabilités .NET (440 % de plus que la base de données publique suivante), Snyk Intel fournit des informations précises et exploitables pour accélérer la correction, notamment les versions des packages concernées et la version vers laquelle effectuer la mise à niveau. Au total, Snyk Intel recense plus de 700 vulnérabilités .NET, dont 63 % sont de gravité élevée ou critique.

Le package UbracoForms en est un exemple intéressant. Utilisé pour intégrer des formulaires et des questionnaires dans des applications, UbracoForms a été téléchargé des centaines de milliers de fois. La dernière version du package, la version 8.8.0, ne présente aucune vulnérabilité, mais les versions précédentes comportent une vulnérabilité critique d’exécution de code à distance (RCE).

Snyk Open Source s’appuie sur ces informations pour déterminer le correctif nécessaire, qui est indiqué dans les conseils de correction et dans les pull requests de correction déclenchées automatiquement.

Regardons cela de plus près.

Conseils de correction .NET dans Snyk Open Source

Snyk s’intègre aux SCM basés sur Git, notamment GitHub, GitHub Enterprise, Azure Repos, GitLab, Bitbucket Server et Bitbucket Cloud. Vous pouvez ainsi facilement importer vos projets, puis détecter et corriger les vulnérabilités (et les problèmes de licence) qu’ils contiennent, le tout dans le cadre de votre workflow de développement habituel.

Importer un projet est simple. Accédez à la page Projects, cliquez sur Add project dans le coin supérieur droit, puis sélectionnez le type de projet à importer (GitHub, Bitbucket, etc.) et le dépôt qui le contient. Pour les besoins de cette démonstration, je vais importer cet exemple d’application, qui contient volontairement des vulnérabilités.

Lors de l’importation du projet, Snyk l’analyse automatiquement pour détecter les problèmes. Dans cet exemple, Snyk Code a identifié un problème dans mon code personnalisé (1), tandis que Snyk Open Source a détecté une liste plus longue de problèmes dans les packages .NET open source que j’utilise (2).

Cliquez sur le fichier de projet .NET pour examiner ces problèmes de plus près.

Au total, 18 problèmes ont été identifiés, et Snyk aide à les corriger de plusieurs façons.

Tout d’abord, dans l’onglet Dependencies, une arborescence complète des dépendances s’affiche. Elle vous offre une visibilité totale sur tous les packages .NET utilisés pour créer votre projet et sur les problèmes qu’ils introduisent : vulnérabilités de sécurité connues et problèmes de licence.

Vous pouvez filtrer l’arborescence pour afficher uniquement les dépendances vulnérables ou celles qui présentent un problème de licence. Vous voyez ainsi clairement comment les problèmes ont été introduits, directement ou par l’intermédiaire de dépendances transitives.

Ensuite, dans l’onglet Fixes, Snyk fournit des conseils pour corriger les vulnérabilités. Tous les problèmes ne sont pas corrigeables, mais pour ceux qui le sont, vous pouvez voir précisément le chemin de mise à niveau à suivre pour appliquer le correctif.

Remarque : Snyk Open Source recommande un chemin de mise à niveau pour les vulnérabilités détectées dans les dépendances directes et transitives, mais uniquement lorsqu’une nouvelle version de la dépendance directe corrige la vulnérabilité.

Dans notre exemple, Snyk nous indique que la mise à niveau du package TinyMCE de la version 4.8.2 vers la version 5.6.0 corrigera 4 vulnérabilités différentes.

Revenons à l’onglet principal Issues. Snyk Open Source y fournit de nombreuses informations pour vous aider à parcourir la liste des problèmes et à hiérarchiser les corrections. La fiche de chaque problème affiche notamment un score de priorité dans son coin supérieur droit, qui vous indique rapidement son degré d’urgence (pour en savoir plus sur le score de priorité de Snyk, cliquez ici), ainsi que le chemin de mise à niveau.

Dans l’exemple ci-dessous, Snyk Open Source a détecté une vulnérabilité critique dans le package Halibut et recommande une mise à niveau vers la version 4.4.7.

Pour corriger la vulnérabilité, vous pouvez déclencher manuellement une pull request en cliquant sur le bouton Fix this vulnerability. Une page s’ouvre et répertorie toutes les vulnérabilités que vous pouvez corriger avec une pull request. Vous pouvez choisir d’en corriger une ou plusieurs en les sélectionnant.

Dans ce cas, je vais m’en tenir à la seule vulnérabilité que je souhaite corriger : celle du package Halibut.

En cliquant sur Open a Fix PR au bas de la page, vous déclenchez la PR, qui s’ouvre ensuite dans le dépôt GitHub concerné pour que je puisse l’examiner.

La pull request contient tout le contexte nécessaire pour décider de la fusionner ou non, notamment des informations sur la vulnérabilité elle-même et sur la portée du correctif proposé.

Snyk déclenche également automatiquement une pull request dans votre dépôt si une nouvelle vulnérabilité est détectée ou si un nouveau correctif devient disponible pour l’une de vos vulnérabilités existantes.

Pour éviter que vous n’introduisiez accidentellement de nouveaux problèmes dans votre projet, Snyk Open Source teste également automatiquement toute nouvelle pull request ouverte par vous ou un autre contributeur du dépôt afin d’y détecter des vulnérabilités ou des licences problématiques.

Pour commencer !

L’écosystème .NET est relativement complexe par rapport à d’autres écosystèmes. Pour gérer et atténuer efficacement les risques liés aux packages .NET open source, il est important de comprendre précisément l’arborescence des dépendances, mais aussi de fournir le contexte et les workflows nécessaires pour agir et corriger les vulnérabilités détectées.

Les nouvelles fonctionnalités de correction de Snyk Open Source aident les équipes de développement et de sécurité à détecter les différents problèmes dans leurs applications, à les corriger au quotidien dans le cadre de leur workflow et à empêcher l’introduction de nouveaux problèmes. Pour en savoir plus sur la prise en main, consultez notre documentation officielle Snyk for .NET.

Si ce n’est pas déjà fait, inscrivez-vous à Snyk pour essayer ! Bonne correction !