Audit des dépendances de package pour les vulnérabilités de sécurité
À 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) | S/O | 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 | S/O | 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.
- À partir de la ligne de commande, accédez au répertoire racine de votre projet ou solution.
- Exécutez
restore
à l’aide de vos outils préférés (c’est-à-dire dotnet, MSBuild, NuGet.exe, VisualStudio, etc.). - 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 | tous (1) | direct et all |
Si vous souhaitez auditer les dépendances de niveau supérieur et transitives, vous pouvez définir la valeur sur all . NuGetAuditMode est non applicable pour les 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 . |
(1) NuGetAuditMode a été défini par défaut sur direct
lorsqu’il a été introduit dans le kit de développement logiciel (SDK) .NET 8.0.100 et VS 17.8. Dans le kit de développement logiciel (SDK) .NET 9.0.100 et VS 17.12, la valeur par défaut est passée à all
.
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>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>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 un paramètre 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.