Häufig gestellte Fragen | Azure

Hinweis

Ab dem 1. März 2022 wird die Erweiterung „Microsoft-Sicherheitscodeanalyse“ (Microsoft Security Code Analysis, MSCA) eingestellt. MSCA-Kunden behalten ihren Zugriff auf die MSCA bis zum 1. März 2022. Das OWASP-Tool für die Quellcodeanalyse bietet alternative Möglichkeiten in Azure DevOps. Kunden, die eine Migration zu GitHub planen, können sich über GitHub Advanced Security informieren.

Haben Sie Fragen? Weitere Informationen finden Sie in den folgenden häufig gestellten Fragen.

Allgemeine häufig gestellte Fragen

Kann ich die Erweiterung für meine Visual Studio Team Foundation Server-Instanz statt für eine Azure DevOps-Instanz installieren?

Nein. Die Erweiterung kann nicht für Visual Studio Team Foundation Server heruntergeladen und installiert werden.

Muss ich die Microsoft-Sicherheitscodeanalyse mit meinem Build ausführen?

Vielleicht. Das hängt vom Typ des Analysetools ab. Möglicherweise ist der Quellcode das einzige, was erforderlich ist, ggf. wird aber auch die Buildausgabe benötigt.

Beispielsweise analysiert Credential Scanner (CredScan) Dateien in der Ordnerstruktur des Coderepositorys. Daher können Sie CredScan und Buildtasks für die Veröffentlichung von Sicherheitsanalyseprotokollen in einem eigenständigen Build ausführen, um Ergebnisse abzurufen.

Für andere Tools wie BinSkim, die Artefakte nach dem Build analysieren, wird zuerst der Build benötigt.

Kann ich meinen Build abbrechen, wenn Ergebnisse gefunden werden?

Ja. Sie können eine Buildunterbrechung vornehmen, wenn ein Tool einen Issue oder ein Problem in seiner Protokolldatei erfasst. Fügen Sie einfach den Buildtask nach der Analyse hinzu, und aktivieren Sie das Kontrollkästchen für jedes Tool, das den Build unterbrechen soll.

Sie können den Build in der Benutzeroberfläche des Tasks nach der Analyse unterbrechen, wenn ein beliebiges Tool nur Fehler oder sowohl Warnungen als auch Fehler meldet.

Wie unterscheiden sich die Befehlszeilenargumente in Azure DevOps von den Argumenten in den eigenständigen Desktoptools?

In den meisten Fällen sind die Azure DevOps-Buildtasks direkte Wrapper um die Befehlszeilenargumente der Sicherheitstools. Alles, was Sie normalerweise an ein Befehlszeilentool übergeben würden, können Sie als Argumente an einen Buildtask übergeben.

Die wichtigsten Unterschiede:

  • Tool werden aus dem Agent-Quellordner $(Build.SourcesDirectory) oder aus %BUILD_SOURCESDIRECTORY% ausgeführt. Beispiel: C:\agent_work\1\s.
  • Pfade in den Argumenten können relativ zum Stammverzeichnis des oben aufgeführten Quellverzeichnisses oder absolut sein. Sie erhalten absolute Pfade entweder mithilfe von Azure DevOps-Buildvariablen oder durch Ausführen eines lokalen Agents, der über bekannte Bereitstellungsspeicherorte für lokale Ressourcen verfügt.
  • Tools stellen automatisch einen Ausgabedateipfad oder -ordner zur Verfügung. Wenn Sie einen Ausgabespeicherort für einen Buildtask angeben, wird dieser entfernt und durch einen Pfad zum bekannten Protokollspeicherort auf dem Build-Agent ersetzt.
  • Für einige Tools werden einige zusätzliche Befehlszeilenargumente geändert. Beispielsweise werden Optionen hinzugefügt oder entfernt, durch die sichergestellt wird, dass keine GUI gestartet wird.

Kann ich einen Buildtask wie Credential Scanner über mehrere Repositorys hinweg in einem Azure DevOps-Build ausführen?

Nein. Das Ausführen der sicheren Entwicklungstools für mehrere Repositorys in einer einzigen Pipeline wird nicht unterstützt.

Die angegebene Ausgabedatei wird nicht erstellt bzw. ich kann die angegebene Ausgabedatei nicht finden.

Durch Buildtasks werden einige Benutzereingaben gefiltert. Konkret zu dieser Frage: Buildtasks aktualisieren den Speicherort der generierten Ausgabedatei, sodass er einem üblichen Speicherort auf dem Build-Agent entspricht. Weitere Informationen zu diesem Speicherort finden Sie in den folgenden Fragen.

Wo werden die von den Tools generierten Ausgabedateien gespeichert?

Die Buildtasks fügen automatisch Ausgabepfade zum bekannten Speicherort auf dem Build-Agent hinzu: $(Agent.BuildDirectory)_sdt\logs. Durch die standardmäßige Verwendung dieses Standort haben alle Teams, die Codeanalyseprotokolle erstellen oder nutzen, Zugriff auf die Ausgabe.

Kann ich einen Build in einer Warteschlange speichern, damit diese Tasks auf einem gehosteten Build-Agent ausgeführt werden?

Ja. Alle Tasks und Tools in der Erweiterung können auf einem gehosteten Build-Agent ausgeführt werden.

Hinweis

Der Schadsoftwarescanner-Buildtask erfordert einen Build-Agent mit aktiviertem Windows Defender. Ein solcher Agent ist ab Hosted Visual Studio 2017 verfügbar. Der Buildtask kann nicht unter Verwendung des gehosteten Agents von Visual Studio 2015 ausgeführt werden.

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

Kann ich diese Buildtasks als Teil einer Releasepipeline ausführen (im Gegensatz zu einer Buildpipeline)?

In den meisten Fällen ist dies möglich.

Die Taskausführung in Releasepipelines wird von Azure DevOps jedoch nicht unterstützt, wenn von diesen Tasks Artefakte veröffentlicht werden. Dadurch wird verhindert, dass der Task zur Veröffentlichung von Sicherheitsanalyseprotokollen erfolgreich in einer Releasepipeline ausgeführt werden kann. Es tritt ein Fehler auf, und eine Fehlermeldung wird ausgegeben.

Von wo laden die Buildtasks die Tools herunter?

Buildtasks können die NuGet-Pakete der Tools aus dem Azure DevOps-Paketverwaltungsfeed herunterladen. Buildtasks können auch den Knotenpaket-Manager verwenden, der auf dem Build-Agent vorinstalliert werden muss. Ein Beispiel für eine solche Installation ist der Befehl npm install tslint.

Welche Auswirkung hat die Installation der Erweiterung auf meine Azure DevOps-Organisation?

Nach der Installation werden die von der Erweiterung bereitgestellten Sicherheitsbuildtasks für alle Benutzer im Unternehmen verfügbar. Beim Erstellen oder Bearbeiten einer Azure-Pipeline sind diese Tasks in der Buildtask-Sammlungsliste verfügbar. Die Installation der Erweiterung in Ihrer Azure DevOps-Organisation hat ansonsten keinerlei Auswirkungen. Bei der Installation werden Kontoeinstellungen, Projekteinstellungen oder Pipelines nicht geändert.

Werden die vorhandenen Azure-Pipelines durch Installieren der Erweiterung geändert?

Nein. Wenn Sie die Erweiterung installieren, werden Sicherheitsbuildtasks verfügbar und können Pipelines hinzugefügt werden. Benutzer müssen weiterhin Builddefinitionen hinzufügen oder aktualisieren, damit die Tools mit dem Buildprozess interagieren können.

Taskbezogene FAQs

In diesem Abschnitt werden Fragen zu Buildtasks behandelt.

Credential Scanner

Was sind allgemeine Unterdrückungsszenarien und wie sehen sie in der Praxis aus?

Im Folgenden finden Sie Details zu zwei der gängigsten Unterdrückungsszenarien:

Unterdrücken aller Vorkommen eines angegebenen Geheimnisses innerhalb des angegebenen Pfads

Der Hashschlüssel des Geheimnisses aus der CredScan-Ausgabedatei ist erforderlich, wie im folgenden Beispiel gezeigt.

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

Warnung

Der Hashschlüssel wird von einem Teil des entsprechenden Werts oder Dateiinhalts generiert. Durch jede Quellcoderevision kann der Hashschlüssel geändert und die Unterdrückungsregel deaktiviert werden.

So unterdrücken Sie alle Geheimnisse in einer angegebenen Datei oder die Geheimnisdatei selbst

Der Dateiausdruck kann ein Dateiname sein. Darüber hinaus kann er der Basename-Teil eines vollständigen Dateipfads oder eines Dateinamens sein. Platzhalter werden nicht unterstützt.

In den folgenden Beispielen wird gezeigt, wie Sie die Datei „<InputPath>\src\JS\lib\angular.js“ unterdrücken.

Beispiele für gültige Unterdrückungsregeln:

  • <InputPath>\src\JS\lib\angular.js: Unterdrückt die Datei im angegebenen Pfad.
  • \src\JS\lib\angular.js
  • \JS\lib\angular.js
  • \lib\angular.js
  • angular.js: unterdrückt alle Dateien mit dem gleichen Namen
{
    "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"
    }
  ]
}

Warnung

Alle zukünftigen Geheimnisse, die der Datei hinzugefügt werden, werden ebenfalls automatisch unterdrückt.

Welche Verwaltungsrichtlinien für Geheimnisse werden empfohlen?

Die folgenden Ressourcen helfen Ihnen, Geheimnisse sicher zu verwalten und von Anwendungen aus sicher auf vertrauliche Informationen zuzugreifen:

Weitere Informationen finden Sie im Blogbeitrag zum sicheren Verwalten von Geheimnissen in der Cloud.

Kann ich meine eigenen benutzerdefinierten Suchroutinen schreiben?

Credential Scanner basiert auf einem Satz von Inhaltssuchroutinen, die üblicherweise in der Datei „buildsearchers.xml“ definiert sind. Die Datei enthält ein Array von serialisierten XML-Objekten, die ein ContentSearcher-Objekt darstellen. Das Programm wird mit einer Reihe von Suchroutinen verteilt, die eingehend getestet wurden. Sie können jedoch auch eigene benutzerdefinierte Suchroutinen implementieren.

Eine Inhaltssuchroutine wird wie folgt definiert:

  • Name: Der beschreibende Name der Suchroutine, der in den Ausgabedateien von Credential Scanner verwendet werden soll. Es wird empfohlen, die Camel-Case-Namenskonvention für Namen von Suchroutinen zu verwenden.

  • RuleId: Die stabile, opake ID der Suchroutine:

    • Standardsuchroutinen von Credential Scanner wird ein RuleId-Wert wie CSCAN0010, CSCAN0020 oder CSCAN0030 zugewiesen. Die letzte Ziffer ist für das Mergen oder Unterteilen von Suchroutinengruppen durch reguläre Ausdrücke (RegEx) reserviert.
    • Der RuleId-Wert für eine angepasste Suchroutine sollte über einen eigenen Namespace verfügen. Beispiele: CSCAN-<Namespace>0010, CSCAN-<Namespace>0020 und CSCAN-<Namespace>0030.
    • Der vollqualifizierte Name der Suchroutine besteht aus der Kombination von RuleId-Wert und Suchroutinennamen. Beispiele sind: CSCAN0010.KeyStoreFiles und CSCAN0020.Base64EncodedCertificate.
  • ResourceMatchPattern: RegEx der Dateierweiterungen, die anhand der Suchroutine überprüft werden sollen.

  • ContentSearchPatterns: Ein Array von Zeichenfolgen mit RegEx-Anweisungen, die abgeglichen werden sollen. Wenn keine Suchmuster definiert sind, werden alle Dateien zurückgegeben, die mit dem ResourceMatchPattern-Wert übereinstimmen.

  • ContentSearchFilters: Ein Array von Zeichenfolgen, das RegEx-Anweisungen enthält, um suchroutinenspezifische falsch positive Ergebnisse zu filtern.

  • MatchDetails: Eine beschreibende Nachricht und/oder Risikominderungsanweisungen, die für jede Übereinstimmung mit der Suchroutine hinzugefügt werden sollen.

  • Empfehlung: Stellt den Inhalt des Vorschlagsfelds für einen Abgleich im PREfast-Berichtsformat zur Verfügung.

  • Schweregrad: Ein Integerwert, der den Schweregrad eines Problems angibt. Der höchste Schweregrad hat den Wert 1.

    XML für Credential Scanner-Setup

Roslyn Analyzers

Welche Fehler treten am häufigsten bei der Verwendung des Roslyn Analyzers-Tasks auf?

Das Projekt wurde mit einer falschen Microsoft.NETCore.App-Version wiederhergestellt.

Vollständige Fehlermeldung:

„Fehler: The project was restored using Microsoft.NETCore.App version x.x.x, but with current settings, version y.y.y would be used instead. (Das Projekt wurde mit Version „x.x.x“ von Microsoft.NETCore.App wiederhergestellt, aber mit den aktuellen Einstellungen würde Version „y.y.y“ verwendet werden). Um dieses Problem zu beheben, stellen Sie sicher, dass die gleichen Einstellungen für die Wiederherstellung und für nachfolgende Vorgänge wie Build- oder Veröffentlichungsvorgänge verwendet werden. Normalerweise tritt dieses Problem auf, wenn die RuntimeIdentifier-Eigenschaft während des Builds oder der Veröffentlichung festgelegt wird, jedoch nicht während der Wiederherstellung.“

Roslyn Analyzers-Tasks werden als Teil der Kompilierung ausgeführt, sodass sich die Quellstruktur auf dem Buildcomputer in einem buildfähigen Zustand befinden muss.

Durch einen Schritt zwischen dem Hauptbuild und den Roslyn Analyzers-Schritten wurde die Quellstruktur u. U. in einen nicht buildfähigen Zustand versetzt. Dieser zusätzliche Schritt ist wahrscheinlich dotnet.exe publish. Versuchen Sie, den Schritt zu duplizieren, durch den kurz vor dem Roslyn Analyzers-Schritt eine NuGet-Wiederherstellung ausgeführt wird. In diesem duplizierten Schritt kann die Quellstruktur ggf. wieder in einen buildfähigen Zustand zurückversetzt werden.

„csc. exe“ kann keine Analysetoolinstanz erstellen

Vollständige Fehlermeldung:

„'csc.exe' exited with error code 1 -- An instance of analyzer AAAA cannot be created from C:\BBBB.dll: Could not load file or assembly 'Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. („csc. exe“ wurde mit dem Fehlercode 1 beendet – Eine Instanz von Analyzer AAAA kann nicht aus „C:\BBBB.dll“ erstellt werden: Die Datei oder Assembly „Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35“ oder eine Abhängigkeit davon wurde nicht geladen. Das System kann die angegebene Datei nicht finden.“

Stellen Sie sicher, dass der Compiler Roslyn Analyzers unterstützt. Beim Ausführen des Befehls csc.exe /version sollte ein Wert mit der Version 2.6 oder höher zurückgegeben werden.

In einigen Fällen können einzelne CSPROJ-Dateien die Visual Studio-Installation des Buildcomputers überschreiben, indem sie auf ein Paket aus Microsoft.Net.Compilers verweisen. Um eine bestimmte Version des Compilers zu verwenden, entfernen Sie Verweise auf Microsoft.Net.Compilers. Stellen Sie andernfalls sicher, dass das referenzierte Paket die Version 2.6 oder höher hat.

Versuchen Sie, den in der Option csc.exe /errorlog angegebenen Fehlerprotokollpfad abzurufen. Die Option und der Pfad werden im Protokoll des Roslyn Analyzers-Buildtasks angezeigt. Der Pfad könnte in etwa so aussehen: /errorlog:F:\ts-services-123_work\456\s\Some\Project\Code\Code.csproj.sarif

Die C# Compilerversion ist nicht aktuell genug.

Die neuesten Versionen des C#-Compilers werden hier veröffentlicht: Microsoft.Net.Compilers. Um die installierte Version abzurufen, führen Sie csc.exe /version an der Eingabeaufforderung aus. Stellen Sie sicher, dass Sie auf ein NuGet-Paket von Microsoft.Net.Compilers verweisen, das mindestens die Version 2.6 aufweist.

MSBuild- und VSBuild-Protokolle nicht gefunden

Durch den Roslyn Analyzers-Buildtask müssen Azure DevOps für das MSBuild-Protokoll aus dem MSBuild-Buildtask abgefragt werden. Wenn der Analysetool-Task unmittelbar nach dem MSBuild-Task ausgeführt wird, ist das Protokoll noch nicht verfügbar. Platzieren Sie andere Tasks zwischen der MSBuild-Task und dem Roslyn Analyzers-Task. Beispiele für andere Tasks sind BinSkim und Schadsoftwarescanner.

Nächste Schritte

Wenn Sie zusätzliche Unterstützung benötigen, ist Support für die Microsoft-Sicherheitscodeanalyse von Montag bis Freitag zwischen 9:00 Uhr und 17:00 Uhr (Pazifik-Standardzeit) verfügbar.