Konfigurieren und Anpassen der Buildaufgaben

Hinweis

Ab dem 31. Dezember 2022 wird die MsCA-Erweiterung (Microsoft Security Code Analysis) eingestellt. MSCA wird durch die Microsoft Security DevOps Azure DevOps Erweiterungersetzt. Befolgen Sie die Anweisungen in Konfigurieren von, um die Erweiterung zu installieren und zu konfigurieren.

In diesem Artikel werden die konfigurationsoptionen ausführlich beschrieben, die in den einzelnen Buildaufgaben verfügbar sind. Der Artikel beginnt mit den Aufgaben für Sicherheitscodeanalysetools. Sie endet mit den Nachbearbeitungsaufgaben.

Anti-Malware Scanner-Aufgabe

Hinweis

Für die Buildaufgabe des Antischadsoftwarescanners ist ein Build-Agent mit aktiviertem Windows Defender erforderlich. Gehostete Visual Studio 2017 und höher stellen einen solchen Agent bereit. Die Buildaufgabe wird nicht auf dem gehosteten Visual Studio 2015-Agent ausgeführt.

Obwohl Signaturen für diese Agents nicht aktualisiert werden können, sollten Signaturen immer weniger als drei Stunden alt sein.

Details zur Aufgabenkonfiguration werden im folgenden Screenshot und Text angezeigt.

Im Listenfeld Typ des Screenshots ist Standard ausgewählt. Wählen Sie Benutzerdefinierte aus, um Befehlszeilenargumente bereitzustellen, die den Scan anpassen.

Windows Defender verwendet den Windows Update-Client zum Herunterladen und Installieren von Signaturen. Wenn das Signaturupdate für Ihren Build-Agent fehlschlägt, stammt der HRESULT- Fehlercode wahrscheinlich von Windows Update.

Weitere Informationen zu Windows Update-Fehlern und deren Entschärfung finden Sie unter Windows Update-Fehlercodes nach Komponenten- und dem TechNet-Artikel Windows Update Agent – Fehlercodes.

Informationen zur YAML-Konfiguration für diese Aufgabe finden Sie in unseren Anti-Malware YAML-Optionen

BinSkim-Aufgabe

Hinweis

Bevor Sie die BinSkim-Aufgabe ausführen können, muss Ihr Build eine der folgenden Bedingungen erfüllen:

• Ihr Build erzeugt binäre Artefakte aus verwaltetem Code.
• Sie haben binäre Artefakte zugesichert, die Sie mit BinSkim analysieren möchten.

Details zur Aufgabenkonfiguration werden im folgenden Screenshot und in der folgenden Liste angezeigt.

• Legen Sie die Buildkonfiguration auf "Debuggen" fest, sodass PDB-Debugdateien erstellt werden. BinSkim verwendet diese Dateien, um Probleme in den Ausgabebinärdateien wieder dem Quellcode zuzuordnen.
• So vermeiden Sie das Recherchieren und Erstellen einer eigenen Befehlszeile:
  • Wählen Sie in der Liste TypBasic-aus.
  • Wählen Sie in der Funktion-Liste Analysierenaus.
• Geben Sie in Ziel-einen oder mehrere Bezeichner für eine Datei, ein Verzeichnis oder ein Filtermuster ein. Diese Bezeichner lösen zu einer oder mehreren Binärdateien auf, die analysiert werden sollen:
  • Mehrere angegebene Ziele müssen durch ein Semikolon (;)) getrennt werden.
  • Ein Bezeichner kann eine einzelne Datei sein oder Wildcards enthalten.
  • Verzeichnisspezifikationen müssen immer mit \*enden.
  • Beispiele

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

• Wenn Sie Befehlszeilen- in der Liste Typ auswählen, müssen Sie binskim.exeausführen:
  • Stellen Sie sicher, dass die ersten Argumente binskim.exe das Verb sind, das analysieren gefolgt von einer oder mehreren Pfadspezifikationen. Jeder Pfad kann entweder ein vollständiger Pfad oder ein Pfad relativ zum Quellverzeichnis sein.
  • Mehrere Zielpfade müssen durch ein Leerzeichen getrennt werden.
  • Sie können die Option /o oder /output weglassen. Der Ausgabewert wird für Sie hinzugefügt oder ersetzt.
  • Standard-Befehlszeilenkonfigurationen werden wie folgt angezeigt.

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

Hinweis

Das nachfolgende \* ist wichtig, wenn Sie Verzeichnisse für das Ziel angeben.

Weitere Informationen zu BinSkim-Befehlszeilenargumenten, Regeln nach ID oder Beendigungscodes finden Sie im BinSkim User Guide.

Informationen zur YAML-Konfiguration für diese Aufgabe finden Sie in unseren BinSkim YAML-Optionen

Aufgabe des Authentifizierungsdaten-Scanners

Details zur Aufgabenkonfiguration werden im folgenden Screenshot und in der folgenden Liste angezeigt.

Folgende Optionen sind verfügbar:

• Anzeigename: Name der Azure DevOps-Aufgabe. Der Standardwert ist Run Credential Scanner
• Tool Hauptversion: Verfügbare Werte umfassen CredScan V2, CredScan V1. Wir empfehlen Kunden, die CredScan V2--Version zu verwenden.
• Ausgabeformat: Verfügbare Werte umfassen TSV, CSV-, SARIF-und PREfast.
• Toolversion: Es wird empfohlen, Neuesteauszuwählen.
• Scanordner: Der zu scannende Repository-Ordner.
• Suchdateityp: Die Optionen zum Suchen der Suchdatei, die zum Scannen verwendet wird.
• Unterdrückungsdatei: Eine JSON- Datei kann Probleme im Ausgabeprotokoll unterdrücken. Weitere Informationen zu Unterdrückungsszenarien finden Sie im Häufig gestellten Abschnitt dieses Artikels.
• Ausführliche Ausgabe: Selbsterklärend.
• Batchgröße: Die Anzahl der gleichzeitigen Threads, die zum Ausführen des Anmeldedaten-Scanners verwendet werden. Der Standardwert ist 20. Mögliche Werte liegen zwischen 1 und 2.147.483.647.
• Timeout für die Spielsuche: Die Dauer in Sekunden, um den Versuch einer Spielsuche abzuschließen, bevor die Überprüfung eingestellt wird.
• Lesepuffergröße: Die Größe in Byte des Puffers, der beim Lesen des Inhalts verwendet wird. Der Standardwert ist 524.288.
• Maximale Anzahl von Lesebytes für dateilesete Bytes: Die maximale Anzahl von Bytes, die während der Inhaltsanalyse aus einer Datei gelesen werden sollen. Der Standardwert ist 104.857.600.
• Steuerelementoptionen>Ausführen dieser Aufgabe: Gibt an, wann die Aufgabe ausgeführt wird. Wählen Sie benutzerdefinierte Bedingungen aus, um komplexere Bedingungen anzugeben.
• Version: Die Version der Build-Aufgabe in Azure DevOps. Diese Option wird nicht häufig verwendet.

Informationen zur YAML-Konfiguration für diese Aufgabe finden Sie in unseren YAML-Optionen

Roslyn Analyzers-Aufgabe

Hinweis

Bevor Sie die Roslyn Analyzers-Aufgabe ausführen können, muss Ihr Build diese Bedingungen erfüllen:

• Ihre Builddefinition enthält die integrierte MSBuild- oder VSBuild-Buildaufgabe zum Kompilieren von C# oder Visual Basic-Code. Die Analyseaufgaben basieren auf der Eingabe und Ausgabe der integrierten Aufgabe, um die MSBuild-Kompilierung mit aktivierten Roslyn-Analysegeräten auszuführen.
• Der Build-Agent, der diese Buildaufgabe ausführt, hat Visual Studio 2017, Version 15.5 oder höher, installiert, sodass er Compilerversion 2.6 oder höher verwendet.

Details zur Aufgabenkonfiguration werden in der folgenden Liste und Notiz angezeigt.

Folgende Optionen sind verfügbar:

• Regelsatz: Werte sind SDL Required, SDL Recommended, oder Ihren eigenen benutzerdefinierten Regelsatz.
• Analyzers Version: Wir empfehlen, Neuesteauszuwählen.
• Compilerwarnungen-Unterdrückungsdatei: Eine Textdatei mit einer Liste von Warnungs-IDs, die unterdrückt werden.
• Steuerelementoptionen>Ausführen dieser Aufgabe: Gibt an, wann die Aufgabe ausgeführt wird. Wählen Sie benutzerdefinierte Bedingungen aus, um komplexere Bedingungen anzugeben.

Hinweis

• Roslyn Analyzers sind in den Compiler integriert und können nur als Teil der csc.exe-Kompilierung ausgeführt werden. Daher erfordert diese Aufgabe, dass der Compilerbefehl, der zuvor im Build ausgeführt wurde, erneut ausgeführt wird. Diese Wiedergabe oder Ausführung erfolgt durch Abfragen von Azure DevOps (vormals Visual Studio Team Services) für die MSBuild-Buildaufgabenprotokolle.

  Es gibt keine andere Möglichkeit für die Aufgabe, die MSBuild-Kompilierungs-Befehlszeile zuverlässig aus der Builddefinition abzurufen. Wir haben in Erwägung gezogen, ein Freihandtextfeld hinzuzufügen, damit Benutzer ihre Befehlszeilen eingeben können. Dann wäre es jedoch schwierig, diese Befehlszeilen up-to-datum und mit dem Hauptbuild zu synchronisieren.

  Benutzerdefinierte Builds erfordern die Wiedergabe des gesamten Befehlssatzes, nicht nur Compilerbefehle. In diesen Fällen ist die Aktivierung von Roslyn Analyzers nicht trivial oder zuverlässig.

• Roslyn Analyzers sind in den Compiler integriert. Um aufgerufen zu werden, benötigen Roslyn Analyzer eine Kompilierung.

  Diese neue Buildaufgabe wird durch erneutes Kompilieren von C#-Projekten implementiert, die bereits erstellt wurden. Die neue Aufgabe verwendet nur die MSBuild- und VSBuild-Buildaufgaben in derselben Build- oder Builddefinition wie die ursprüngliche Aufgabe. In diesem Fall verwendet die neue Aufgabe sie jedoch mit aktivierten Roslyn Analyzers.

  Wenn die neue Aufgabe auf demselben Agent wie die ursprüngliche Aufgabe ausgeführt wird, überschreibt die Ausgabe der neuen Aufgabe die Ausgabe der ursprünglichen Aufgabe im Ordner Quellen. Obwohl die Build-Ausgabe identisch ist, empfehlen wir, MSBuild auszuführen, die Ausgabe in das Staging-Verzeichnis der Artefakte zu kopieren und anschließend die Roslyn-Analyser auszuführen.

Weitere Ressourcen für den Roslyn Analyzer-Vorgang finden Sie in den Roslyn-basierten Analysatoren.

Sie finden das Analysepaket, das von diesem Build-Task installiert und verwendet wird, auf der NuGet-Seite Microsoft.CodeAnalysis.FxCopAnalyzers.

Informationen zur YAML-Konfiguration für diese Aufgabe finden Sie in unseren Roslyn Analyzers YAML-Optionen

TSLint-Vorgang

Weitere Informationen zu TSLint finden Sie im TSLint GitHub-Repository.

Hinweis

Wie Ihnen vielleicht bekannt ist, wird auf der Startseite des TSLint GitHub-Repositorys erwähnt, dass TSLint im Laufe des Jahres 2019 abgeschafft wird. Microsoft untersucht ESLint als alternative Aufgabe.

Informationen zur YAML-Konfiguration für diese Aufgabe finden Sie in unseren TSLint YAML-Optionen

Aufgabe "Sicherheitsanalyseprotokolle veröffentlichen"

Details zur Aufgabenkonfiguration werden im folgenden Screenshot und in der folgenden Liste angezeigt.

• Artefaktname: Beliebige Zeichenfolgenkennung.
• Artefakttyp: Je nach Auswahl können Sie Protokolle auf Ihrem Azure DevOps Server oder in einer freigegebenen Datei veröffentlichen, auf die der Build-Agent zugreifen kann.
• Tools: Sie können sich entscheiden, Protokolle für bestimmte Tools beizubehalten, oder Sie können Alle Tools auswählen, um alle Protokolle beizubehalten.

Informationen zur YAML-Konfiguration für diese Aufgabe finden Sie in unseren YaML-Optionen zum Veröffentlichen von Sicherheitsprotokollen

Vorgang "Sicherheitsbericht"

Details zur Konfiguration des Sicherheitsberichts werden im folgenden Screenshot und in der folgenden Liste angezeigt.

• Berichte: Wählen Sie eines der Formate Pipeline-Konsole, TSV-Dateiund HTML-Datei. Für jedes ausgewählte Format wird eine Berichtsdatei erstellt.
• Tools: Wählen Sie die Tools in Ihrer Builddefinition aus, für die Sie eine Zusammenfassung der erkannten Probleme benötigen. Für jedes ausgewählte Tool gibt es möglicherweise eine Option, um auszuwählen, ob nur Fehler angezeigt werden oder sowohl Fehler als auch Warnungen im Zusammenfassungsbericht angezeigt werden.
• Erweiterte Optionen: Wenn keine Protokolle für eines der ausgewählten Tools vorhanden sind, können Sie eine Warnung oder einen Fehler protokollieren. Wenn Sie einen Fehler protokollieren, schlägt die Aufgabe fehl.
• Basisprotokollordner: Sie können den Basisprotokollordner anpassen, in dem Protokolle gefunden werden sollen. Diese Option wird jedoch in der Regel nicht verwendet.

Informationen zur YAML-Konfiguration für diese Aufgabe finden Sie in unserem Sicherheitsbericht über YAML-Optionen

Aufgabe nach der Analyse

Details zur Aufgabenkonfiguration werden im folgenden Screenshot und in der folgenden Liste angezeigt.

• Tools: Wählen Sie die Tools in Ihrer Builddefinition aus, für die Sie unter bestimmten Bedingungen einen Build-Abbruch einfügen möchten. Für jedes ausgewählte Tool gibt es möglicherweise eine Option, mit der Sie auswählen können, ob nur bei Fehlern oder sowohl bei Fehlern als auch bei Warnungen die Ausführung unterbrochen werden soll.
• Bericht: Sie können optional die Ergebnisse festhalten, die den Build-Abbruch verursachen. Die Ergebnisse werden in das Azure DevOps-Konsolenfenster und die Protokolldatei geschrieben.
• Erweiterte Optionen: Wenn keine Protokolle für eines der ausgewählten Tools vorhanden sind, können Sie eine Warnung oder einen Fehler protokollieren. Wenn Sie einen Fehler protokollieren, schlägt die Aufgabe fehl.

Informationen zur YAML-Konfiguration für diese Aufgabe finden Sie in unseren Post-Analyse-YAML-Optionen

Nächste Schritte

Informationen zur YAML-basierten Konfiguration finden Sie in unserem YAML-Konfigurationshandbuch.

Wenn Sie weitere Fragen zur Erweiterung "Sicherheitscodeanalyse" und den angebotenen Tools haben, schauen Sie sich unserer FAQ-Seitean.