Partager via

Audit des dépendances de package pour les vulnérabilités de sécurité

  • Article

À propos des audits de sécurité

Un audit de sécurité pour les gestionnaires de packages comme NuGet est un processus qui implique l’analyse de la sécurité des packages inclus dans un projet logiciel. Cela implique d’identifier les vulnérabilités, d’évaluer les risques et de formuler des recommandations pour en améliorer la sécurité. L’audit peut inclure un examen des packages eux-mêmes, ainsi que de toutes les dépendances et de leurs risques associés. L’objectif de l’audit est d’identifier et d’atténuer les failles de sécurité qui pourraient être exploitées par des attaquants, tels que l’injection de code ou les attaques basées sur le scripting inter-site.

Nous publions également un billet de blog qui décrit la méthode d’action recommandée lorsqu’un package avec une vulnérabilité connue est utilisé par votre projet et des outils pour obtenir plus d’informations.

Disponibilité des fonctionnalités

NuGet Kit de développement logiciel (SDK) .NET Visual Studio Fonctionnalité
5.9 Kit de développement logiciel (SDK) .NET 5 (5.0.200) N/A dotnet list package --vulnerable
6.8 Kit de développement logiciel (SDK) .NET 8 (8.0.100) Visual Studio 2022 17.8 NuGetAudit pour PackageReference
6.10 N/A Visual Studio 2022 17.10 NuGetAudit pour packages.config
6.11 Kit de développement logiciel (SDK) .NET 8 (8.0.400) Visual Studio 2022 17.11 NuGetAuditSuppress pour PackageReference
6.12 Kit de développement logiciel (SDK) .NET 9 (9.0.100) Visual Studio 2022 17.12 Sources de l’audit. NuGetAuditSuppress pour packages.config.

Exécution d’un audit de sécurité avec restore

La commande restore s’exécute automatiquement lorsque vous effectuez une opération de package courante, comme le chargement d’un projet pour la première fois, l’ajout d’un nouveau package, la mise à jour d’une version de package ou la suppression d’un package de votre projet dans votre IDE favori. Vos dépendances sont vérifiées par rapport à une liste de vulnérabilités connues fournies par les sources de l’audit.

  1. À partir de la ligne de commande, accédez au répertoire racine de votre projet ou solution.
  2. Exécutez restore à l’aide de vos outils préférés (c’est-à-dire dotnet, MSBuild, NuGet.exe, VisualStudio, etc.).
  3. Passez en revue les avertissements et résolvez les failles de sécurité connues.

Configuration de l’audit NuGet

L’audit peut être configuré via des propriétés MSBuild dans un fichier .csproj ou MSBuild évalué dans le cadre de votre projet. Nous vous recommandons de configurer l’audit au niveau d’un référentiel.

Propriété MSBuild Par défaut Valeurs possibles Notes
NuGetAuditMode all direct et all Si vous souhaitez auditer uniquement les dépendances de niveau supérieur, vous pouvez définir la valeur sur direct. NuGetAuditMode n’est pas applicable aux projets packages.config.
NuGetAuditLevel  Faible low, moderate, high et critical Le niveau de gravité minimal pour le rapport. Si vous souhaitez voir les avertissements moderate, high et critical (low exclus), définissez la valeur sur moderate
NuGetAudit true true et false Si vous souhaitez ne pas recevoir de rapports d’audit de sécurité, vous pouvez refuser entièrement l’expérience en définissant la valeur sur false.

Remarque : Dans .NET 8, la valeur par défaut de NuGetAuditMode est direct. Par conséquent, la définition de SdkAnalysisLevel pour 8.0.400 modifier la valeur par défaut de NuGetAuditMode en conséquence.

Sources de l’audit

Rétablir télécharge la ressource VulnerabilityInfo d’un serveur pour la vérifier par rapport à la liste des packages utilisés par chaque projet. La liste des sources est définie par l’élément auditSources dans NuGet.Config et l’avertissement NU1905 se déclenche si l’une des sources de l’audit ne fournit aucune information sur les vulnérabilités. Si auditSources n’est pas défini ou est effacé sans ajouter de sources, alors packageSources est utilisé et l’avertissement NU1905 est supprimé.

Étant donné qu’une prévention courante des attaques de substitution de package consiste à utiliser une source de package unique en amont de nuget.org, de sorte que NuGet n’est pas configuré pour utiliser nuget.org comme source de package, les sources de l’audit peuvent être utilisées pour nuget.org (ou toute autre source qui fournit des informations sur les vulnérabilités) sans l’utiliser également comme source de package.

La source de données pour la base de données des vulnérabilités de nuget.org est GitHub Advisory Database. Notez que le protocole V2 est déconseillé. Par conséquent, si votre fichier nuget.config utilise toujours le point de terminaison V2, vous devez migrer vers le point de terminaison V3.

<configuration>
    <auditSources>
        <clear />
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    </auditSources>
</configuration>

Les sources de l’audit sont disponibles à partir de NuGet 6.12, du kit de développement logiciel (SDK) .NET 9.0.100 et de Visual Studio 2022 17.12. Dans les versions antérieures, l’audit NuGet utilise uniquement les sources de package pour télécharger les informations de vulnérabilité. Les sources de l’audit ne sont pas utilisées par dotnet list package --vulnerable pour le moment.

Exclusion des avertissements

Vous pouvez choisir d’exclure des avertissements spécifiques du rapport d’audit en ajoutant un nouvel élément MSBuild NuGetAuditSuppress pour chaque avertissement. Définissez un élément NuGetAuditSuppress avec les métadonnées Include= définies sur l’URL d’avertissement que vous souhaitez supprimer.

<ItemGroup>
    <NuGetAuditSuppress Include="https://github.com/advisories/XXXX" />
</ItemGroup>

Comme pour les autres propriétés de configuration d’audit NuGet, les éléments NuGetAuditSuppress peuvent être définis au niveau du projet ou du référentiel.

NuGetAuditSuppress est disponible pour les projets PackageReference à partir de NuGet 6.11, Visual Studio 17.11 et du Kit de développement logiciel (SDK) .NET 8.0.400. Il est disponible pour packages.config dans Visual Studio 17.12 et NuGet 6.12.

Codes d’avertissement

Code d’avertissement Motif
NU1900 Erreur de communication avec la source du package, durant l’obtention des informations sur les vulnérabilités.
NU1901 Package avec une gravité faible détectée
NU1902 Package avec gravité modérée détectée
NU1903 Package avec une gravité élevée détectée
NU1904 Package avec gravité critique détectée
NU1905 Une source de l’audit ne fournit pas de base de données des vulnérabilités

Vous pouvez personnaliser votre génération pour traiter ces avertissements comme des erreurs pour traiter les avertissements comme des erreurs ou ne pas traiter les avertissements comme des erreurs. Par exemple, si vous utilisez déjà <TreatWarningsAsErrors> pour traiter tous les avertissements (C#, NuGet, MSBuild, etc.), vous pouvez utiliser <WarningsNotAsErrors>$(WarningsNotAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors> pour empêcher les vulnérabilités découvertes à l’avenir de casser votre génération. Sinon, si vous souhaitez conserver des vulnérabilités faibles et modérées en tant qu’avertissements, mais traitez les vulnérabilités élevées et critiques comme des erreurs, et que vous n’utilisez pas TreatWarningsAsErrors, vous pouvez utiliser <WarningsAsErrors>$(WarningsAsErrors);NU1903;NU1904</WarningsAsErrors>.

Remarque

Les propriétés MSBuild pour la gravité des messages, telles que NoWarn et TreatWarningsAsErrors ne sont pas prises en charge pour les projets packages.config.

dotnet list package --vulnerable

Une fois qu’un projet a été restauré avec succès, dotnet list package dispose d’un argument --vulnerable pour filtrer les packages en fonction des vulnérabilités connues des packages. Notez que --include-transitive ce n’est pas par défaut. Il doit donc être inclus.

Actions à prendre lorsque des packages avec des vulnérabilités connues sont signalés

Nous publions également un billet de blog qui décrit la méthode d’action recommandée lorsqu’un package avec une vulnérabilité connue est utilisé par votre projet et des outils pour obtenir plus d’informations.

Failles de sécurité trouvées avec les mises à jour

Si des failles de sécurité sont détectées et que des mises à jour sont disponibles pour le package concerné, vous pouvez :

  • Modifiez l’emplacement .csproj ou un autre emplacement de version du package (Directory.Packages.props) avec une version plus récente qui contient un correctif de sécurité.
  • Utilisez l’interface utilisateur du gestionnaire de package NuGet de Visual Studio pour mettre à jour individuellement le package.
  • Exécutez la commande dotnet add package avec l’ID associé au package pour effectuer la mise à jour vers la dernière version.

Packages transitifs

Si une vulnérabilité connue existe dans les dépendances transitives d’un package de niveau supérieur, vous disposez de ces options :

  • Ajoutez la version fixe du package en tant que référence de package direct. Remarque : veillez à supprimer cette référence lorsqu’une nouvelle mise à jour de version du package devient disponible et veillez à conserver les attributs définis pour le comportement attendu.
  • Utilisez la gestion centralisée des packages avec la fonctionnalité d’épinglage transitive.
  • Supprimez l’avis jusqu’à ce qu’il puisse être traité.
  • Déposez un problème dans le suivi du package de niveau supérieur pour demander une mise à jour.

Failles de sécurité trouvées sans mises à jour

Dans le cas où une vulnérabilité connue existe dans un package sans qu’aucun correctif de sécurité ne soit proposé, vous pouvez effectuer les opérations suivantes.

  • Vérifiez les facteurs d’atténuation décrits dans le rapport d’avertissement.
  • Utilisez un package suggéré si le package est marqué déprécié ou abandonné.
  • Si le package est open source, vous pouvez contribuer à un correctif pour celui-ci.
  • Ouvrez un problème dans le suivi des problèmes du package.

Vérifier les facteurs d’atténuation

Passez en revue le bulletin de sécurité pour voir s'il existe des facteurs d'atténuation qui vous permettraient de continuer à utiliser le package présentant la vulnérabilité. La vulnérabilité peut exister uniquement lorsque le code est utilisé sur un framework, un système d’exploitation ou lorsqu’une une fonction spéciale spécifique est appelée.

Utiliser un package suggéré

Dans le cas où un avis de sécurité est signalé pour le package que vous utilisez et que le package est marqué comme déconseillé ou semble abandonné, envisagez d'utiliser tout package alternatif suggéré que l'auteur du package a déclaré ou un package comprenant des fonctionnalités similaires qui est maintenu.

Contribuer à un correctif

Si aucun correctif n’existe pour l’avis de sécurité, vous pouvez suggérer des modifications qui traitent la vulnérabilité dans une demande de tirage (pull request) sur le référentiel open source du package ou contactez l’auteur via la section Contact owners de la page de détails du package NuGet.org.

Ouvrir un problème

Si vous ne souhaitez pas corriger la vulnérabilité ou que vous ne pouvez pas mettre à jour ou remplacer le package, ouvrez un problème dans le suivi des problèmes du package ou utilisez la méthode de contact préférée. Sur NuGet.org, vous pouvez accéder à la page des détails du package et cliquer sur Report package. Cela vous permettra de contacter l’auteur.

Aucune faille de sécurité décelée

Si aucune faille de sécurité n’est trouvée, cela signifie que les packages avec des vulnérabilités connues ne sont pas présents dans votre graphe de package au moment où vous avez effectué l’analyse. Étant donné que la base de données d’avertissement peut être mise à jour à tout moment, nous vous recommandons de vérifier régulièrement votre sortie dotnet restore et d’en faire de même dans votre processus d’intégration continue.

Résumé

Les fonctionnalités d’audit de sécurité sont essentielles pour maintenir la sécurité et l’intégrité des projets de logiciels. Ces fonctionnalités vous offrent une couche de protection supplémentaire contre les failles de sécurité et vous permettent d’utiliser des packages open source en toute confiance.