Configurer et personnaliser les tâches de génération

Remarque

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

Cet article décrit en détail les options de configuration disponibles dans chacune des tâches de génération. L’article commence par les tâches des outils d’analyse du code de sécurité. Elle se termine par les tâches de post-traitement.

Tâche de scanner anti-malware

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, elles doivent toujours dater de moins de trois heures.

Les détails de la configuration des tâches sont présentés dans la capture d’écran et le texte suivants.

Dans la zone de liste Type de la capture d’écran, Basic est sélectionné. Sélectionnez Personnalisé pour fournir des arguments de ligne de commande qui personnalisent l’analyse.

Windows Defender utilise le client Windows Update pour télécharger et installer des signatures. Si la mise à jour de signature échoue sur votre agent de build, le code d’erreur HRESULT provient probablement de Windows Update.

Pour plus d’informations sur les erreurs Windows Update et leur atténuation, consultez les codes d’erreur Windows Update par composant et l’article TechNet de l’agent Windows Update - Codes d’erreur.

Pour plus d'informations sur la configuration YAML de cette tâche, consultez nos options antimalware YAML

Tâche BinSkim

Remarque

Avant de pouvoir exécuter la tâche BinSkim, votre build doit respecter l’une des conditions suivantes :

• Votre build produit des artefacts binaires à partir du code managé.
• Vous avez commis des artefacts binaires que vous souhaitez analyser avec BinSkim.

Les détails de la configuration des tâches sont affichés dans la capture d’écran et la liste suivantes.

• Définissez la configuration de build sur Déboguer afin que les fichiers de débogage .pdb soient générés. BinSkim utilise ces fichiers pour mapper les problèmes dans les fichiers binaires de sortie au code source.
• Pour éviter de rechercher et de créer votre propre ligne de commande :
  • Dans la liste Type , sélectionnez De base.
  • Dans la liste des fonctions , sélectionnez Analyser.
• Dans Target, entrez un ou plusieurs spécificateurs pour un modèle de fichier, de répertoire ou de filtre. Ces spécificateurs se résolvent en un ou plusieurs binaires à analyser :
  • Plusieurs cibles spécifiées doivent être séparées par un point-virgule (;).
  • Un spécificateur peut être un seul fichier ou contenir des caractères génériques.
  • Les spécifications de répertoire doivent toujours se terminer par \*.
  • Exemples:

           *.dll;*.exe
           $(BUILD_STAGINGDIRECTORY)\*
           $(BUILD_STAGINGDIRECTORY)\*.dll;$(BUILD_STAGINGDIRECTORY)\*.exe;

• Si vous sélectionnez Ligne de commande dans la liste Type , vous devez exécuter binskim.exe:
  • Vérifiez que les premiers arguments à binskim.exe sont le verbe analyser suivi d’une ou plusieurs spécifications de chemin d’accès. Chaque chemin peut être un chemin complet ou un chemin d’accès relatif au répertoire source.
  • Plusieurs chemins cibles doivent être séparés par un espace.
  • Vous pouvez omettre l’option /o ou /output . La valeur de sortie est ajoutée pour vous ou remplacée.
  • Les configurations de ligne de commande standard sont indiquées comme suit.

           analyze $(Build.StagingDirectory)\* --recurse --verbose
           analyze *.dll *.exe --recurse --verbose

Remarque

Le \* de fin est important si vous spécifiez des répertoires pour la cible.

Pour plus d’informations sur les arguments de ligne de commande BinSkim, les règles par ID ou les codes de sortie, consultez le Guide de l’utilisateur BinSkim.

Pour plus d’informations sur la configuration YAML pour cette tâche, consultez nos options YAML BinSkim

Tâche d’analyseur d’informations d’identification

Les détails de la configuration des tâches sont affichés dans la capture d’écran et la liste suivantes.

Les options disponibles sont les suivantes :

• Nom d'affichage : nom de la tâche Azure DevOps. La valeur par défaut est Exécuter le scanneur d’informations d’identification
• Version principale de l’outil : Les valeurs disponibles incluent CredScan V2, CredScan V1. Nous vous recommandons d’utiliser la version CredScan V2 .
• Format de sortie : Les valeurs disponibles incluent TSV, CSV, SARIF et PREfast.
• Version de l’outil : nous vous recommandons de sélectionner La dernière version.
• Dossier d’analyse : dossier du référentiel à analyser.
• Type de fichier des searchers : options de localisation du fichier de recherche utilisé pour l’analyse.
• Fichier de suppressions : un fichier JSON peut supprimer les problèmes dans le journal de sortie. Pour plus d’informations sur les scénarios de suppression, consultez la section FAQ de cet article.
• Sortie détaillée : auto-explicatif.
• Taille du lot : nombre de threads simultanés utilisés pour exécuter le scanneur d’informations d’identification. La valeur par défaut est 20. Les valeurs possibles sont comprises entre 1 et 2 147 483 647.
• Délai d’expiration de correspondance : durée en secondes pendant laquelle tenter de trouver une correspondance avec l'analyseur de recherche avant d'abandonner la vérification.
• Taille de la mémoire tampon de lecture de l’analyse de fichier : taille en octets de la mémoire tampon utilisée pendant la lecture du contenu. La valeur par défaut est 524 288.
• Nombre maximal d’octets de lecture d’analyse de fichier : nombre maximal d’octets à lire à partir d’un fichier pendant l’analyse du contenu. La valeur par défaut est 104 857 600.
• Options> de contrôleExécutez cette tâche : spécifie quand la tâche s’exécutera. Sélectionnez Des conditions personnalisées pour spécifier des conditions plus complexes.
• Version : version de la tâche de compilation dans Azure DevOps. Cette option n’est pas fréquemment utilisée.

Pour plus d’informations sur la configuration YAML pour cette tâche, consultez nos options YAML du scanneur d’informations d’identification

Tâche des Analyseurs Roslyn

Remarque

Avant de pouvoir exécuter la tâche Analyseurs Roslyn, votre build doit répondre à ces conditions :

• Votre définition de build inclut la tâche de génération intégrée MSBuild ou VSBuild pour compiler du code C# ou Visual Basic. La tâche d’analyseurs s’appuie sur l’entrée et la sortie de la tâche intégrée pour exécuter la compilation MSBuild avec les analyseurs Roslyn activés.
• L’agent de build exécutant cette tâche de génération a Visual Studio 2017 version 15.5 ou ultérieure installée, afin qu’elle utilise le compilateur version 2.6 ou ultérieure.

Les détails de la configuration des tâches sont affichés dans la liste et la remarque suivantes.

Les options disponibles sont les suivantes :

• Ensemble de règles : les valeurs sont SDL Obligatoires, SDL Recommandés ou votre propre ensemble de règles personnalisé.
• Version des analyseurs : nous vous recommandons de sélectionner La dernière version.
• Fichier suppressions d’avertissements du compilateur : fichier texte avec une liste d’ID d’avertissements supprimés.
• Options> de contrôleExécutez cette tâche : spécifie quand la tâche s’exécutera. Choisissez des conditions personnalisées pour spécifier des conditions plus complexes.

Remarque

• Les analyseurs Roslyn sont intégrés au compilateur et peuvent être exécutés uniquement dans le cadre de csc.exe compilation. Par conséquent, cette tâche nécessite que la commande du compilateur qui a été exécutée précédemment dans la compilation soit rejouée ou réexécutée. Cette réexécution ou exécution est effectuée en interrogeant les journaux des tâches de compilation MSBuild dans Azure DevOps (anciennement Visual Studio Team Services).

  Il n’existe aucun autre moyen pour la tâche d’obtenir de manière fiable la ligne de commande de compilation MSBuild à partir de la définition de build. Nous avons envisagé d’ajouter une zone de texte de forme libre pour permettre aux utilisateurs d’entrer leurs lignes de commande. Mais il serait difficile de conserver ces lignes de commande up-to-date et synchronisées avec la build principale.

  Les builds personnalisées nécessitent une relecture de l’ensemble des commandes, pas seulement des commandes du compilateur. Dans ces cas, l’activation de Roslyn Analyzers n’est pas triviale ou fiable.

• Les analyseurs Roslyn sont intégrés au compilateur. Pour être appelés, les analyseurs Roslyn nécessitent une compilation.

  Cette nouvelle tâche de génération est implémentée en recompilant les projets C# qui ont déjà été créés. La nouvelle tâche utilise uniquement les tâches de build MSBuild et VSBuild dans la même build ou définition de build que la tâche d’origine. Toutefois, dans ce cas, la nouvelle tâche les utilise avec Roslyn Analyzers activés.

  Si la nouvelle tâche s’exécute sur le même agent que la tâche d’origine, la sortie de la nouvelle tâche remplace la sortie de la tâche d’origine dans le dossier sources. Bien que la sortie de build soit identique, nous vous conseillons d’exécuter MSBuild, de copier la sortie dans le répertoire intermédiaire des artefacts, puis d’exécuter Roslyn Analyzers.

Pour des ressources supplémentaires concernant la tâche des analyseurs basés sur Roslyn, examinez les analyseurs basés sur Roslyn .

Vous trouverez le package d’analyseur installé et utilisé par cette tâche de génération sur la page NuGet Microsoft.CodeAnalysis.FxCopAnalyzers.

Pour plus d’informations sur la configuration YAML pour cette tâche, consultez nos options YAML Roslyn Analyzers

Tâche TSLint

Pour plus d’informations sur TSLint, accédez au dépôt GitHub TSLint.

Remarque

Comme vous le savez peut-être, la page d’accueil du dépôt GitHub TSLint indique que TSLint sera déprécié à un moment donné en 2019. Microsoft étudie ESLint comme autre tâche.

Pour plus d’informations sur la configuration YAML pour cette tâche, consultez nos options TSLint YAML

Tâche Publier les journaux d’activité d’analyse de la sécurité

Les détails de la configuration des tâches sont affichés dans la capture d’écran et la liste suivantes.

• Nom de l’artefact : tout identificateur de chaîne.
• Type d’artefact : selon votre sélection, vous pouvez publier les journaux sur votre serveur Azure DevOps ou dans un fichier partagé auquel l’agent de build a accès.
• Outils : vous pouvez choisir de conserver les journaux d’activité pour des outils spécifiques, ou vous pouvez sélectionner Tous les outils pour conserver tous les journaux.

Pour plus d’informations sur la configuration YAML de cette tâche, consultez nos options YAML de publication des journaux de sécurité

Tâche rapport de sécurité

Les détails de la configuration du rapport de sécurité sont affichés dans la capture d’écran et la liste suivantes.

• Rapports : sélectionnez l'un des formats console de pipeline, fichier TSV et fichier Html. Un fichier de rapport est créé pour chaque format sélectionné.
• Outils : sélectionnez les outils de votre définition de build pour lesquels vous souhaitez obtenir un résumé des problèmes détectés. Pour chaque outil sélectionné, il peut y avoir une option permettant de sélectionner si vous voyez uniquement des erreurs ou si vous voyez des erreurs et des avertissements dans le rapport de synthèse.
• Options avancées : s’il n’existe aucun journal pour l’un des outils sélectionnés, vous pouvez choisir de consigner un avertissement ou une erreur. Si vous consignez une erreur, la tâche échoue.
• Dossier journaux de base : vous pouvez personnaliser le dossier des journaux de base où se trouvent les journaux. Mais cette option n’est généralement pas utilisée.

Pour plus d’informations sur la configuration YAML pour cette tâche, consultez nos options YAML du rapport de sécurité

Tâche post-analyse

Les détails de la configuration des tâches sont affichés dans la capture d’écran et la liste suivantes.

• Outils : sélectionnez les outils de votre définition de build pour lesquels vous souhaitez injecter conditionnellement un saut de build. Pour chaque outil sélectionné, il peut y avoir une option permettant de choisir si vous souhaitez vous interrompre uniquement sur les erreurs ou sur les erreurs et les avertissements également.
• Rapport : vous pouvez éventuellement écrire les résultats à l’origine de l’arrêt de build. Les résultats sont écrits dans la fenêtre de console Azure DevOps et dans le fichier journal.
• Options avancées : s’il n’existe aucun journal pour l’un des outils sélectionnés, vous pouvez choisir de consigner un avertissement ou une erreur. Si vous consignez une erreur, la tâche échoue.

Pour plus d’informations sur la configuration YAML de cette tâche, consultez nos options YAML Post Analyse

Étapes suivantes

Pour plus d’informations sur la configuration basée sur YAML, reportez-vous à notre guide de configuration YAML .

Si vous avez d’autres questions sur l’extension Analyse du code de sécurité et les outils proposés, consultez notre page FAQ.