Forum aux questions | Azur

Remarque

À compter du 31 décembre 2022, l’extension Microsoft Security Code Analysis (MSCA) est supprimée. MSCA est remplacé par la l’extension Microsoft Security DevOps Azure DevOps. Suivez les instructions de Configurer pour installer et configurer l’extension.

FAQ générale

Puis-je installer l’extension sur mon instance Azure DevOps Server (anciennement Visual Studio Team Foundation Server) au lieu d’une instance Azure DevOps ?

Non. L’extension n’est pas disponible pour le téléchargement et l’installation d’Azure DevOps Server (anciennement Visual Studio Team Foundation Server).

Dois-je exécuter Microsoft Security Code Analysis avec ma build ?

Peut-être. Cela dépend du type d’outil d’analyse. Le code source peut être la seule chose requise, ou la sortie de build peut être requise.

Par exemple, Credential Scanner (CredScan) analyse les fichiers dans la structure de dossiers du référentiel de code. En raison de cette analyse, vous pouvez exécuter les tâches de génération CredScan et Publier des journaux d’analyse de la sécurité dans une build autonome pour obtenir des résultats.

Pour d’autres outils tels que BinSkim qui analysent les artefacts post-build, la build est requise en premier.

Puis-je interrompre ma génération lorsque les résultats sont trouvés ?

Oui. Vous pouvez introduire un saut de build quand un outil signale un problème ou un problème dans son fichier journal. Ajoutez la tâche de génération post-analyse, puis cochez la case correspondant à n’importe quel outil pour lequel vous souhaitez interrompre la génération.

Dans l’interface utilisateur de la tâche post-analyse, vous pouvez choisir d’interrompre la génération quand un outil signale uniquement des erreurs ou des avertissements.

Comment les arguments de ligne de commande dans Azure DevOps diffèrent-ils de ces arguments dans les outils de bureau autonomes ?

En règle générale, les tâches de génération Azure DevOps sont des wrappers directs autour des arguments de ligne de commande des outils de sécurité. Vous pouvez passer en tant qu’arguments à une tâche de génération tout ce que vous transmettez normalement à un outil en ligne de commande.

Différences notables :

• Les outils s’exécutent à partir du dossier source de l’agent $(Build.SourcesDirectory) ou à partir de %BUILD_SOURCESDIRECTORY%. Par exemple, C :\agent_work\1\s.
• Les chemins d’accès dans les arguments peuvent être relatifs à la racine du répertoire source précédemment répertorié. Les chemins d’accès peuvent également être absolus. Vous obtenez des chemins absolus à l’aide de variables de build Azure DevOps ou en exécutant un agent local avec des emplacements de déploiement connus des ressources locales.
• Les outils fournissent automatiquement un chemin d’accès ou un dossier de fichier de sortie. Si vous fournissez un emplacement de sortie pour une tâche de génération, cet emplacement est remplacé par un chemin d’accès à notre emplacement connu des journaux d’activité sur l’agent de build
• D’autres arguments de ligne de commande sont modifiés pour certains outils. L’ajout ou la suppression d’options qui garantissent qu’aucune interface graphique utilisateur n’est lancée.

Puis-je exécuter une tâche de génération telle que Credential Scanner sur plusieurs référentiels dans une build Azure DevOps ?

Non. L’exécution des outils de développement sécurisés sur plusieurs référentiels dans un seul pipeline n’est pas prise en charge.

Le fichier de sortie que j’ai spécifié n’est pas en cours de création, ou je ne trouve pas le fichier de sortie que j’ai spécifié

Les tâches de génération filtrent une entrée utilisateur. Pour cette question spécifiquement, ils mettent à jour l’emplacement du fichier de sortie généré pour qu’il s’agit d’un emplacement commun sur l’agent de build. Pour plus d’informations sur cet emplacement, consultez les questions suivantes.

Où sont les fichiers de sortie générés par les outils enregistrés ?

Les tâches de génération ajoutent automatiquement des chemins de sortie à cet emplacement connu sur l’agent de build : $(Agent.BuildDirectory)_sdt\logs. Étant donné que nous standardlons sur cet emplacement, toutes les équipes qui produisent ou consomment des journaux d’analyse du code ont accès à la sortie.

Puis-je mettre en file d’attente une build pour exécuter ces tâches sur un agent de build hébergé ?

Oui. Toutes les tâches et outils de l’extension peuvent être exécutés sur un agent de build hébergé.

Remarque

La tâche de génération du scanneur anti-programmes malveillants nécessite qu’un agent de build avec Windows Defender soit activé. Visual Studio 2017 hébergé et versions ultérieures fournissent un tel agent. La tâche de génération ne s’exécutera pas sur l’agent hébergé visual Studio 2015.

Bien que les signatures ne puissent pas être mises à jour sur ces agents, les signatures doivent toujours être antérieures à trois heures.

Puis-je exécuter ces tâches de génération dans le cadre d’un pipeline de mise en production par opposition à un pipeline de build ?

Dans la plupart des cas, oui.

Toutefois, Azure DevOps ne prend pas en charge l’exécution de tâches dans des pipelines de mise en production lorsque ces tâches publient des artefacts. Ce manque de prise en charge empêche la tâche Publier les journaux d’analyse de la sécurité de s’exécuter correctement dans un pipeline de mise en production. La tâche échoue à la place avec un message d’erreur descriptif.

À partir de quel emplacement les tâches de génération téléchargent-ils les outils ?

Les tâches de génération peuvent télécharger les packages NuGet des outils à partir du flux de gestion des packages Azure DevOps . Les tâches de génération peuvent également utiliser le Gestionnaire de package Node, qui doit être préinstallé sur l’agent de build. Par exemple, cette installation est la commande npm install tslint.

Quel est l’effet de l’installation de l’extension sur mon organisation Azure DevOps ?

Lors de leur installation, les tâches de build de sécurité fournies par l’extension sont disponibles pour tous les utilisateurs de votre organisation. Lorsque vous créez ou modifiez un pipeline Azure, ces tâches sont disponibles à partir de la liste de regroupements de tâches de build. Sinon, l’installation de l’extension dans votre organisation Azure DevOps n’a aucun effet. L’installation ne modifie aucun paramètre de compte, paramètres de projet ou pipelines.

L’installation de l’extension modifie-t-elle mes pipelines Azure existants ?

Non. L’installation de l’extension rend les tâches de build de sécurité disponibles pour l’ajout de vos pipelines. Vous devez toujours ajouter ou mettre à jour des définitions de build afin que les outils puissent fonctionner avec votre processus de génération.

Questions fréquentes (FAQ) spécifiques à la tâche

Les questions spécifiques aux tâches de génération sont répertoriées dans cette section.

Scanneur d’informations d’identification

Quels sont les scénarios et exemples de suppression courants ?

Voici les détails de deux des scénarios de suppression les plus courants.

Pour supprimer toutes les occurrences d’un secret donné dans le chemin d’accès spécifié

La clé de hachage du secret à partir du fichier de sortie CredScan est requise, comme indiqué dans l’exemple suivant.

{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "hash": "CLgYxl2FcQE8XZgha9/UbKLTkJkUh3Vakkxh2CAdhtY=",
        "_justification": "Secret used by MSDN sample, it is fake."
    }
  ]
}

Avertissement

La clé de hachage est générée par une partie de la valeur correspondante ou du contenu du fichier. Toute révision du code source peut modifier la clé de hachage et désactiver la règle de suppression.

Pour supprimer tous les secrets dans un fichier spécifié ou pour supprimer le fichier de secrets lui-même

L’expression de fichier peut être un nom de fichier. Il peut également s’agir de la partie nom de base d’un chemin d’accès de fichier complet ou d’un nom de fichier. Les caractères génériques ne sont pas pris en charge.

Les exemples suivants montrent comment supprimer le fichier <InputPath>\src\JS\lib\angular.js

Exemples de règles de suppression valides :

• <InputPath>\src\JS\lib\angular.js : supprime le fichier dans le chemin d’accès spécifié
• \src\JS\lib\angular.js
• \JS\lib\angular.js
• \lib\angular.js
• angular.js : supprime n’importe quel fichier portant le même nom

{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "file": "\\files\\AdditonalSearcher.xml", 
        "_justification": "Additional CredScan searcher specific to my team"
    },
    {
        "file": "\\files\\unittest.pfx", 
        "_justification": "Legitimate UT certificate file with private key"
    }
  ]
}

Avertissement

Tous les secrets futurs ajoutés au fichier seront également supprimés automatiquement.

Quelles sont les instructions recommandées pour la gestion des secrets ?

Les ressources suivantes vous aident à gérer en toute sécurité les secrets et à accéder aux informations sensibles à partir de vos applications :

• Azure Key Vault
• Azure Active Directory (Azure AD)
• MSI (Managed Service Identity) Azure AD
• Identités managées pour les ressources Azure
• identités managées dans Azure App Service et Azure Functions
• bibliothèque AppAuthentication

Pour plus d’informations, consultez le billet de blog Gestion sécurisée des secrets dans le cloud.

Puis-je écrire mes propres moteurs de recherche personnalisés ?

Le scanneur d’informations d’identification s’appuie sur un ensemble d’analyseurs de contenu couramment définis dans le fichier buildsearchers.xml. Le fichier contient un tableau d’objets sérialisés XML qui représentent un objet ContentSearcher. Le programme est distribué avec un ensemble de recherche bien testés. Mais vous pouvez également implémenter vos propres moteurs de recherche personnalisés.

Un moteur de recherche de contenu est défini comme suit :

• Nom: nom descriptif de l’analyseur de recherche à utiliser dans les fichiers de sortie du scanneur d’informations d’identification. Nous vous recommandons d’utiliser la convention d’affectation de noms de cas chameau pour les noms d’analyseur de recherche.

• RuleId: ID opaque stable de l’analyseur de recherche :

  • Un analyseur d’informations d’identification par défaut reçoit une valeur RuleId comme CSCAN0010, CSCAN0020 ou CSCAN0030. Le dernier chiffre est réservé à la fusion ou à la division des groupes de recherche par le biais d’expressions régulières (regex).
  • La valeur RuleId pour un moteur de recherche personnalisé doit avoir son propre espace de noms. Les exemples incluent CSCAN-<Namespace>0010, CSCAN-<Namespace>0020 et CSCAN-<Namespace>0030.
  • Un nom de recherche complet est la combinaison d’un RuleId valeur et d’un nom d’appelant de recherche. Les exemples incluent CSCAN0010. KeyStoreFiles et CSCAN0020. Base64EncodedCertificate.

• ResourceMatchPattern: Regex of file extensions to check against the searcher.

• ContentSearchPatterns: tableau de chaînes contenant des instructions regex à mettre en correspondance. Si aucun modèle de recherche n’est défini, tous les fichiers correspondant à la valeur ResourceMatchPattern sont retournés.

• ContentSearchFilters: tableau de chaînes contenant des instructions regex pour filtrer les faux positifs spécifiques à l’analyseur de recherche.

• MatchDetails: message descriptif, instructions d’atténuation ou les deux à ajouter pour chaque correspondance de l’analyseur de recherche.

• recommandation: contenu de champ suggestions pour une correspondance à l’aide du format de rapport PREfast.

• gravité : entier qui reflète le niveau de gravité d’un problème. Le niveau de gravité le plus élevé a la valeur 1.

  

Analyseurs Roslyn

Quelles sont les erreurs courantes lors de l’utilisation de la tâche Analyseurs Roslyn ?

Le projet a été restauré à l’aide d’une version incorrecte Microsoft.NETCore.App

Message d’erreur complet :

« Erreur : Le projet a été restauré à l’aide de Microsoft.NETCore.App version x.x.x, mais avec les paramètres actuels, la version y.y.y serait utilisée à la place. Pour résoudre ce problème, vérifiez que les mêmes paramètres sont utilisés pour la restauration et pour les opérations suivantes telles que la génération ou la publication. En règle générale, ce problème peut se produire si la propriété RuntimeIdentifier est définie pendant la génération ou la publication, mais pas lors de la restauration. »

Étant donné que les tâches Roslyn Analyzers s’exécutent dans le cadre de la compilation, l’arborescence source sur l’ordinateur de build doit être dans un état pouvant être généré.

Une étape entre votre build principale et les étapes de Roslyn Analyzers peut avoir placé l’arborescence source dans un état qui empêche la génération. Cette étape supplémentaire est probablement dotnet.exe publier. Essayez de dupliquer l’étape qui effectue une restauration NuGet juste avant l’étape Analyseurs Roslyn. Cette étape dupliquée peut remettre l’arborescence source dans un état pouvant être généré.

csc.exe ne peut pas créer d’instance d’analyseur

Message d’erreur complet :

« 'csc.exe' quitté avec le code d’erreur 1 - Une instance d’analyseur AAAA ne peut pas être créée à partir de C :\BBBB.dll : Impossible de charger le fichier ou l’assembly 'Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35 » ou l’une de ses dépendances. Le système ne peut pas trouver le fichier spécifié. »

Vérifiez que votre compilateur prend en charge les analyseurs Roslyn. L’exécution de la commande csc.exe /version doit signaler une valeur de version 2.6 ou ultérieure.

Parfois, un fichier .csproj peut remplacer l’installation de Visual Studio de la machine de build en référençant un package à partir de Microsoft.Net.Compilers. Si vous n’avez pas l’intention d’utiliser une version spécifique du compilateur, supprimez les références à Microsoft.Net.Compilers. Sinon, vérifiez que la version du package référencé est également 2.6 ou ultérieure.

Essayez d’obtenir le chemin d’accès au journal des erreurs, qui est spécifié dans l’option /errorlogcsc.exe. L’option et le chemin d’accès s’affichent dans le journal de la tâche de génération Roslyn Analyzers. Ils peuvent ressembler à /errorlog :F :\ts-services-123_work\456\s\Some\Project\Code\Code.csproj.sarif

La version du compilateur C# n’est pas assez récente

Pour obtenir les dernières versions du compilateur C#, accédez à Microsoft.Net.Compilers. Pour obtenir votre version installée, exécutez csc.exe /version à l’invite de commandes. Vérifiez que vous référencez un package NuGet Microsoft.Net.Compilers version 2.6 ou ultérieure.

Les journaux MSBuild et VSBuild ne sont pas trouvés

La tâche de génération Roslyn Analyzers doit interroger Azure DevOps pour le journal MSBuild à partir de la tâche de génération MSBuild. Si la tâche de l’analyseur s’exécute immédiatement après la tâche MSBuild, le journal n’est pas encore disponible. Placez d’autres tâches entre la tâche MSBuild et la tâche Analyseurs Roslyn. Parmi d’autres tâches, citons BinSkim et Le scanneur anti-programmes malveillants.

Étapes suivantes

Si vous avez besoin d’aide supplémentaire, le support technique analyse du code de sécurité Microsoft est disponible le lundi au vendredi de 9h00 à 17h00 heure standard du Pacifique.

• Intégration : reportez-vous à notre documentation d’intégration

• Support : Envoyez un e-mail à notre équipe à support microsoft Security Code Analysis

Remarque

À compter du 31 décembre 2022, l’extension Microsoft Security Code Analysis (MSCA) est supprimée. MSCA est remplacé par la l’extension Microsoft Security DevOps Azure DevOps. Suivez les instructions de Configurer pour installer et configurer l’extension.

Non. L’extension n’est pas disponible pour le téléchargement et l’installation d’Azure DevOps Server (anciennement Visual Studio Team Foundation Server).

Peut-être. Cela dépend du type d’outil d’analyse. Le code source peut être la seule chose requise, ou la sortie de build peut être requise.

Par exemple, Credential Scanner (CredScan) analyse les fichiers dans la structure de dossiers du référentiel de code. En raison de cette analyse, vous pouvez exécuter les tâches de génération CredScan et Publier des journaux d’analyse de la sécurité dans une build autonome pour obtenir des résultats.

Pour d’autres outils tels que BinSkim qui analysent les artefacts post-build, la build est requise en premier.

Oui. Vous pouvez introduire un saut de build quand un outil signale un problème ou un problème dans son fichier journal. Ajoutez la tâche de génération post-analyse, puis cochez la case correspondant à n’importe quel outil pour lequel vous souhaitez interrompre la génération.

Dans l’interface utilisateur de la tâche post-analyse, vous pouvez choisir d’interrompre la génération quand un outil signale uniquement des erreurs ou des avertissements.

En règle générale, les tâches de génération Azure DevOps sont des wrappers directs autour des arguments de ligne de commande des outils de sécurité. Vous pouvez passer en tant qu’arguments à une tâche de génération tout ce que vous transmettez normalement à un outil en ligne de commande.

Différences notables :

• Les outils s’exécutent à partir du dossier source de l’agent $(Build.SourcesDirectory) ou à partir de %BUILD_SOURCESDIRECTORY%. Par exemple, C :\agent_work\1\s.
• Les chemins d’accès dans les arguments peuvent être relatifs à la racine du répertoire source précédemment répertorié. Les chemins d’accès peuvent également être absolus. Vous obtenez des chemins absolus à l’aide de variables de build Azure DevOps ou en exécutant un agent local avec des emplacements de déploiement connus des ressources locales.
• Les outils fournissent automatiquement un chemin d’accès ou un dossier de fichier de sortie. Si vous fournissez un emplacement de sortie pour une tâche de génération, cet emplacement est remplacé par un chemin d’accès à notre emplacement connu des journaux d’activité sur l’agent de build
• D’autres arguments de ligne de commande sont modifiés pour certains outils. L’ajout ou la suppression d’options qui garantissent qu’aucune interface graphique utilisateur n’est lancée.

Non. L’exécution des outils de développement sécurisés sur plusieurs référentiels dans un seul pipeline n’est pas prise en charge.

Les tâches de génération filtrent une entrée utilisateur. Pour cette question spécifiquement, ils mettent à jour l’emplacement du fichier de sortie généré pour qu’il s’agit d’un emplacement commun sur l’agent de build. Pour plus d’informations sur cet emplacement, consultez les questions suivantes.

Les tâches de génération ajoutent automatiquement des chemins de sortie à cet emplacement connu sur l’agent de build : $(Agent.BuildDirectory)_sdt\logs. Étant donné que nous standardlons sur cet emplacement, toutes les équipes qui produisent ou consomment des journaux d’analyse du code ont accès à la sortie.

Oui. Toutes les tâches et outils de l’extension peuvent être exécutés sur un agent de build hébergé.

Remarque

La tâche de génération du scanneur anti-programmes malveillants nécessite qu’un agent de build avec Windows Defender soit activé. Visual Studio 2017 hébergé et versions ultérieures fournissent un tel agent. La tâche de génération ne s’exécutera pas sur l’agent hébergé visual Studio 2015.

Bien que les signatures ne puissent pas être mises à jour sur ces agents, les signatures doivent toujours être antérieures à trois heures.

Dans la plupart des cas, oui.

Toutefois, Azure DevOps ne prend pas en charge l’exécution de tâches dans des pipelines de mise en production lorsque ces tâches publient des artefacts. Ce manque de prise en charge empêche la tâche Publier les journaux d’analyse de la sécurité de s’exécuter correctement dans un pipeline de mise en production. La tâche échoue à la place avec un message d’erreur descriptif.

Les tâches de génération peuvent télécharger les packages NuGet des outils à partir du flux de gestion des packages Azure DevOps . Les tâches de génération peuvent également utiliser le Gestionnaire de package Node, qui doit être préinstallé sur l’agent de build. Par exemple, cette installation est la commande npm install tslint.

Lors de leur installation, les tâches de build de sécurité fournies par l’extension sont disponibles pour tous les utilisateurs de votre organisation. Lorsque vous créez ou modifiez un pipeline Azure, ces tâches sont disponibles à partir de la liste de regroupements de tâches de build. Sinon, l’installation de l’extension dans votre organisation Azure DevOps n’a aucun effet. L’installation ne modifie aucun paramètre de compte, paramètres de projet ou pipelines.

Non. L’installation de l’extension rend les tâches de build de sécurité disponibles pour l’ajout de vos pipelines. Vous devez toujours ajouter ou mettre à jour des définitions de build afin que les outils puissent fonctionner avec votre processus de génération.

Questions fréquentes (FAQ) spécifiques à la tâche

Les questions spécifiques aux tâches de génération sont répertoriées dans cette section.

Voici les détails de deux des scénarios de suppression les plus courants.

Pour supprimer toutes les occurrences d’un secret donné dans le chemin d’accès spécifié

La clé de hachage du secret à partir du fichier de sortie CredScan est requise, comme indiqué dans l’exemple suivant.

{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "hash": "CLgYxl2FcQE8XZgha9/UbKLTkJkUh3Vakkxh2CAdhtY=",
        "_justification": "Secret used by MSDN sample, it is fake."
    }
  ]
}

Avertissement

La clé de hachage est générée par une partie de la valeur correspondante ou du contenu du fichier. Toute révision du code source peut modifier la clé de hachage et désactiver la règle de suppression.

Pour supprimer tous les secrets dans un fichier spécifié ou pour supprimer le fichier de secrets lui-même

L’expression de fichier peut être un nom de fichier. Il peut également s’agir de la partie nom de base d’un chemin d’accès de fichier complet ou d’un nom de fichier. Les caractères génériques ne sont pas pris en charge.

Les exemples suivants montrent comment supprimer le fichier <InputPath>\src\JS\lib\angular.js

Exemples de règles de suppression valides :

• <InputPath>\src\JS\lib\angular.js : supprime le fichier dans le chemin d’accès spécifié
• \src\JS\lib\angular.js
• \JS\lib\angular.js
• \lib\angular.js
• angular.js : supprime n’importe quel fichier portant le même nom

{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "file": "\\files\\AdditonalSearcher.xml", 
        "_justification": "Additional CredScan searcher specific to my team"
    },
    {
        "file": "\\files\\unittest.pfx", 
        "_justification": "Legitimate UT certificate file with private key"
    }
  ]
}

Avertissement

Tous les secrets futurs ajoutés au fichier seront également supprimés automatiquement.

Les ressources suivantes vous aident à gérer en toute sécurité les secrets et à accéder aux informations sensibles à partir de vos applications :

• Azure Key Vault
• Azure Active Directory (Azure AD)
• MSI (Managed Service Identity) Azure AD
• Identités managées pour les ressources Azure
• identités managées dans Azure App Service et Azure Functions
• bibliothèque AppAuthentication

Pour plus d’informations, consultez le billet de blog Gestion sécurisée des secrets dans le cloud.

Le scanneur d’informations d’identification s’appuie sur un ensemble d’analyseurs de contenu couramment définis dans le fichier buildsearchers.xml. Le fichier contient un tableau d’objets sérialisés XML qui représentent un objet ContentSearcher. Le programme est distribué avec un ensemble de recherche bien testés. Mais vous pouvez également implémenter vos propres moteurs de recherche personnalisés.

Un moteur de recherche de contenu est défini comme suit :

• Nom: nom descriptif de l’analyseur de recherche à utiliser dans les fichiers de sortie du scanneur d’informations d’identification. Nous vous recommandons d’utiliser la convention d’affectation de noms de cas chameau pour les noms d’analyseur de recherche.

• RuleId: ID opaque stable de l’analyseur de recherche :

  • Un analyseur d’informations d’identification par défaut reçoit une valeur RuleId comme CSCAN0010, CSCAN0020 ou CSCAN0030. Le dernier chiffre est réservé à la fusion ou à la division des groupes de recherche par le biais d’expressions régulières (regex).
  • La valeur RuleId pour un moteur de recherche personnalisé doit avoir son propre espace de noms. Les exemples incluent CSCAN-<Namespace>0010, CSCAN-<Namespace>0020 et CSCAN-<Namespace>0030.
  • Un nom de recherche complet est la combinaison d’un RuleId valeur et d’un nom d’appelant de recherche. Les exemples incluent CSCAN0010. KeyStoreFiles et CSCAN0020. Base64EncodedCertificate.

• ResourceMatchPattern: Regex of file extensions to check against the searcher.

• ContentSearchPatterns: tableau de chaînes contenant des instructions regex à mettre en correspondance. Si aucun modèle de recherche n’est défini, tous les fichiers correspondant à la valeur ResourceMatchPattern sont retournés.

• ContentSearchFilters: tableau de chaînes contenant des instructions regex pour filtrer les faux positifs spécifiques à l’analyseur de recherche.

• MatchDetails: message descriptif, instructions d’atténuation ou les deux à ajouter pour chaque correspondance de l’analyseur de recherche.

• recommandation: contenu de champ suggestions pour une correspondance à l’aide du format de rapport PREfast.

• gravité : entier qui reflète le niveau de gravité d’un problème. Le niveau de gravité le plus élevé a la valeur 1.

  

Le projet a été restauré à l’aide d’une version incorrecte Microsoft.NETCore.App

Message d’erreur complet :

« Erreur : Le projet a été restauré à l’aide de Microsoft.NETCore.App version x.x.x, mais avec les paramètres actuels, la version y.y.y serait utilisée à la place. Pour résoudre ce problème, vérifiez que les mêmes paramètres sont utilisés pour la restauration et pour les opérations suivantes telles que la génération ou la publication. En règle générale, ce problème peut se produire si la propriété RuntimeIdentifier est définie pendant la génération ou la publication, mais pas lors de la restauration. »

Étant donné que les tâches Roslyn Analyzers s’exécutent dans le cadre de la compilation, l’arborescence source sur l’ordinateur de build doit être dans un état pouvant être généré.

Une étape entre votre build principale et les étapes de Roslyn Analyzers peut avoir placé l’arborescence source dans un état qui empêche la génération. Cette étape supplémentaire est probablement dotnet.exe publier. Essayez de dupliquer l’étape qui effectue une restauration NuGet juste avant l’étape Analyseurs Roslyn. Cette étape dupliquée peut remettre l’arborescence source dans un état pouvant être généré.

csc.exe ne peut pas créer d’instance d’analyseur

Message d’erreur complet :

« 'csc.exe' quitté avec le code d’erreur 1 - Une instance d’analyseur AAAA ne peut pas être créée à partir de C :\BBBB.dll : Impossible de charger le fichier ou l’assembly 'Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35 » ou l’une de ses dépendances. Le système ne peut pas trouver le fichier spécifié. »

Vérifiez que votre compilateur prend en charge les analyseurs Roslyn. L’exécution de la commande csc.exe /version doit signaler une valeur de version 2.6 ou ultérieure.

Parfois, un fichier .csproj peut remplacer l’installation de Visual Studio de la machine de build en référençant un package à partir de Microsoft.Net.Compilers. Si vous n’avez pas l’intention d’utiliser une version spécifique du compilateur, supprimez les références à Microsoft.Net.Compilers. Sinon, vérifiez que la version du package référencé est également 2.6 ou ultérieure.

Essayez d’obtenir le chemin d’accès au journal des erreurs, qui est spécifié dans l’option /errorlogcsc.exe. L’option et le chemin d’accès s’affichent dans le journal de la tâche de génération Roslyn Analyzers. Ils peuvent ressembler à /errorlog :F :\ts-services-123_work\456\s\Some\Project\Code\Code.csproj.sarif

La version du compilateur C# n’est pas assez récente

Pour obtenir les dernières versions du compilateur C#, accédez à Microsoft.Net.Compilers. Pour obtenir votre version installée, exécutez csc.exe /version à l’invite de commandes. Vérifiez que vous référencez un package NuGet Microsoft.Net.Compilers version 2.6 ou ultérieure.

Les journaux MSBuild et VSBuild ne sont pas trouvés

La tâche de génération Roslyn Analyzers doit interroger Azure DevOps pour le journal MSBuild à partir de la tâche de génération MSBuild. Si la tâche de l’analyseur s’exécute immédiatement après la tâche MSBuild, le journal n’est pas encore disponible. Placez d’autres tâches entre la tâche MSBuild et la tâche Analyseurs Roslyn. Parmi d’autres tâches, citons BinSkim et Le scanneur anti-programmes malveillants.

Étapes suivantes

Si vous avez besoin d’aide supplémentaire, le support technique analyse du code de sécurité Microsoft est disponible le lundi au vendredi de 9h00 à 17h00 heure standard du Pacifique.

• Intégration : reportez-vous à notre documentation d’intégration

• Support : Envoyez un e-mail à notre équipe à support microsoft Security Code Analysis