Häufig gestellte Fragen | Azurblau

Nein. Die Erweiterung steht nicht zum Herunterladen und Installieren für Azure DevOps Server (vormals Visual Studio Team Foundation Server) zur Verfügung.

Vielleicht. Dies hängt vom Typ des Analysetools ab. Der Quellcode ist möglicherweise das einzige, was erforderlich ist, oder die Buildausgabe ist möglicherweise erforderlich.

Beispielsweise analysiert der Anmeldeinformationsscanner (CredScan) Dateien innerhalb der Ordnerstruktur des Code-Repositorys. Aufgrund dieser Analyse können Sie die Buildaufgaben von CredScan und Publish Security Analysis Logs in einem eigenständigen Build ausführen, um Ergebnisse zu erhalten.

Bei anderen Tools wie BinSkim, die Nachbuildartefakte analysieren, ist der Build zuerst erforderlich.

Ja. Sie können eine Buildunterbrechung einführen, wenn jedes Tool ein Problem oder Problem in der Protokolldatei meldet. Fügen Sie die Buildaufgabe nach der Analyse hinzu, und aktivieren Sie das Kontrollkästchen für jedes Tool, für das Sie den Build unterbrechen möchten.

Auf der Benutzeroberfläche der Aufgabe nach der Analyse können Sie den Build unterbrechen, wenn ein Tool entweder Nur Fehler oder sowohl Fehler als auch Warnungen meldet.

In der Regel sind die Azure DevOps-Buildaufgaben direkte Wrapper um die Befehlszeilenargumente der Sicherheitstools. Sie können als Argumente an eine Buildaufgabe übergeben, was Sie normalerweise an ein Befehlszeilentool übergeben.

Spürbare Unterschiede:

• Tools werden aus dem Quellordner des Agents $(Build.SourcesDirectory) oder aus %BUILD_SOURCESDIRECTORY%ausgeführt. Ein Beispiel ist C:\agent_work\1\s.
• Pfade in den Argumenten können relativ zum Stammverzeichnis des zuvor aufgeführten Quellverzeichnisses sein. Pfade können auch absolut sein. Sie erhalten absolute Pfade entweder mithilfe von Azure DevOps Build Variables oder durch Ausführen eines lokalen Agents mit bekannten Bereitstellungsspeicherorten lokaler Ressourcen.
• Tools stellen automatisch einen Ausgabedateipfad oder -ordner bereit. Wenn Sie einen Ausgabespeicherort für eine Buildaufgabe angeben, wird dieser Speicherort durch einen Pfad zu unserem bekannten Speicherort von Protokollen am Build-Agent ersetzt.
• Einige andere Befehlszeilenargumente werden für einige Tools geändert. Ein Beispiel ist das Hinzufügen oder Entfernen von Optionen, die sicherstellen, dass keine GUI gestartet wird.

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

Die Buildaufgaben filtern einige Benutzereingaben. Für diese Frage aktualisieren sie insbesondere den Speicherort der generierten Ausgabedatei auf einen gemeinsamen Speicherort für den Build-Agent. Weitere Informationen zu diesem Speicherort finden Sie in den folgenden Fragen.

Die Buildaufgaben fügen automatisch Ausgabepfade zu diesem bekannten Speicherort im Build-Agent hinzu: $(Agent.BuildDirectory)_sdt\logs. Da wir an diesem Speicherort standardisieren, haben alle Teams, die Codeanalyseprotokolle produzieren oder nutzen, Zugriff auf die Ausgabe.

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

In den meisten Fällen ja.

Azure DevOps unterstützt jedoch das Ausführen von Aufgaben in Releasepipelines nicht, wenn diese Aufgaben Artefakte veröffentlichen. Dieser Mangel an Unterstützung verhindert, dass die Aufgabe "Sicherheitsanalyseprotokolle veröffentlichen" erfolgreich in einer Releasepipeline ausgeführt wird. Die Aufgabe schlägt stattdessen mit einer beschreibenden Fehlermeldung fehl.

Buildaufgaben können die NuGet-Pakete der Tools aus dem Azure DevOps-Paketverwaltungsfeedherunterladen. Buildaufgaben können auch den Node Package Manager verwenden, der auf dem Build-Agent vorinstalliert sein muss. Ein Beispiel für eine solche Installation ist der Befehl npm install tslint.

Nach der Installation werden die von der Erweiterung bereitgestellten Sicherheitsbuildaufgaben für alle Benutzer in Ihrer Organisation verfügbar. Wenn Sie eine Azure-Pipeline erstellen oder bearbeiten, stehen diese Aufgaben in der Buildaufgabensammlungsliste zur Verfügung. Andernfalls hat die Installation der Erweiterung in Ihrer Azure DevOps-Organisation keine Auswirkung. Die Installation ändert keine Kontoeinstellungen, Projekteinstellungen oder Pipelines.

Nein. Durch die Installation der Erweiterung werden die Sicherheitsbuildaufgaben zusätzlich zu Ihren Pipelines zur Verfügung gestellt. Sie müssen weiterhin Builddefinitionen hinzufügen oder aktualisieren, damit die Tools mit Ihrem Buildprozess arbeiten können.

Aufgabenspezifische Häufig gestellte Fragen

Fragen zu Buildaufgaben sind in diesem Abschnitt aufgeführt.

Hier sind Details zu zwei der am häufigsten verwendeten Unterdrückungsszenarien.

So unterdrücken Sie alle Vorkommen eines bestimmten geheimen Schlüssels innerhalb des angegebenen Pfads

Der Hashschlüssel des geheimen Schlüssels 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."
    }
  ]
}

So unterdrücken Sie alle geheimen Schlüssel in einer angegebenen Datei oder um die geheime Datei selbst zu unterdrücken

Der Dateiausdruck kann ein Dateiname sein. Er kann auch der Basisnameteil eines vollständigen Dateipfads oder eines Dateinamens sein. Wildcards werden nicht unterstützt.

Die folgenden Beispiele zeigen, wie die Datei <InputPath->\src\JS\lib\angular.js unterdrückt wird.

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 jede Datei mit demselben 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"
    }
  ]
}

Mithilfe der folgenden Ressourcen können Sie geheime Schlüssel sicher verwalten und in Ihren Anwendungen auf vertrauliche Informationen zugreifen:

• Azure Key Vault
• Azure Active Directory (Azure AD)
• azure AD Managed Service Identity (MSI)-
• Verwaltete Identitäten für Azure-Ressourcen
• verwaltete Identitäten in Azure App Service und Azure Functions
• AppAuthentication-Bibliothek

Weitere Informationen finden Sie im Blogbeitrag Sicheres Verwalten von Geheimschlüsseln in der Cloud.

Der Anmeldeinformationsscanner basiert auf einer Reihe von Inhaltssuchern, die häufig in der buildsearchers.xml-Datei definiert sind. Die Datei enthält ein Array serialisierter XML-Objekte, die ein ContentSearcher--Objekt darstellen. Das Programm wird mit einer Reihe gut getesteter Sucher verteilt. Sie können aber auch eigene benutzerdefinierte Sucher implementieren.

Ein Inhaltssuchprogramm ist wie folgt definiert:

• Name: Der beschreibende Suchername, der in Ausgabedateien des Anmeldeinformationsscanners verwendet werden soll. Es wird empfohlen, die Namenskonvention für Kamelfälle für Suchernamen zu verwenden.

• RuleId: Die stabile undurchsichtige ID des Suchers:

  • Einem Standardsuchprogramm für Anmeldeinformationsscanner wird ein RuleId Wert wie CSCAN0010, CSCAN0020 oder CSCAN0030 zugewiesen. Die letzte Ziffer ist für das Zusammenführen oder Dividieren von Suchgruppen über reguläre Ausdrücke (regex) reserviert.
  • Der RuleId- Wert für einen angepassten Sucher sollte über einen eigenen Namespace verfügen. Beispiele sind CSCAN-<Namespace>0010, CSCAN-<Namespace>0020 und CSCAN-<Namespace>0030.
  • Ein vollqualifizierter Suchername ist die Kombination aus einem RuleId Wert und einem Suchnamen. Beispiele sind CSCAN0010. KeyStoreFiles und CSCAN0020. Base64EncodedCertificate.

• ResourceMatchPattern: Regex von Dateierweiterungen, um die Suche nachzuprüfen.

• ContentSearchPatterns: Ein Array von Zeichenfolgen, die regex-Anweisungen enthalten, die übereinstimmen. Wenn keine Suchmuster definiert sind, werden alle Dateien zurückgegeben, die dem ResourceMatchPattern Wert entsprechen.

• ContentSearchFilters: Ein Array von Zeichenfolgen, die regex-Anweisungen enthalten, um sucherspezifische falsch positive Ergebnisse zu filtern.

• MatchDetails: Eine beschreibende Meldung, Entschärfungsanweisungen oder beides, die für jede Übereinstimmung des Suchers hinzugefügt werden sollen.

• Empfehlung: Der Vorschlagsfeldinhalt für eine Übereinstimmung mithilfe des PREfast-Berichtsformats.

• Schweregrad: Eine ganze Zahl, die den Schweregrad eines Problems widerspiegelt. Der höchste Schweregrad weist den Wert 1 auf.

  

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

Die vollständige Fehlermeldung:

"Fehler: Das Projekt wurde mit Microsoft.NETCore.App Version x.x.xwiederhergestellt, aber mit den aktuellen Einstellungen wird stattdessen version y.y.y.y verwendet. Um dieses Problem zu beheben, stellen Sie sicher, dass dieselben Einstellungen für die Wiederherstellung und für nachfolgende Vorgänge wie Build oder Veröffentlichung verwendet werden. In der Regel kann dieses Problem auftreten, wenn die RuntimeIdentifier-Eigenschaft während des Builds oder veröffentlichen, aber nicht während der Wiederherstellung festgelegt wird."

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

Ein Schritt zwischen Dem Hauptbuild und Roslyn Analyzers könnte die Quellstruktur in einen Zustand versetzt haben, der das Erstellen verhindert. Dieser zusätzliche Schritt ist wahrscheinlich dotnet.exe veröffentlichen. Versuchen Sie, den Schritt zu duplizieren, der eine NuGet-Wiederherstellung direkt vor dem Schritt "Roslyn Analyzers" durchführt. Dieser duplizierte Schritt versetzt die Quellstruktur möglicherweise wieder in einen buildierbaren Zustand.

csc.exe kann keine Analyseinstanz erstellen.

Die vollständige Fehlermeldung:

"'csc.exe' mit Fehlercode 1 beendet - Eine Instanz von Analyzer AAAA- kann nicht aus C:\BBBB-.dll erstellt werden: Datei oder Assembly 'Microsoft.CodeAnalysis konnte nicht geladen werden, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35' oder eine ihrer Abhängigkeiten. Das System kann die angegebene Datei nicht finden."

Stellen Sie sicher, dass Ihr Compiler Roslyn Analyzers unterstützt. Wenn Sie den Befehl csc.exe /version ausführen, sollte der Versionswert 2.6 oder höher angegeben werden.

Manchmal kann eine CSPROJ-Datei die Visual Studio-Installation des Buildcomputers überschreiben, indem auf ein Paket von Microsoft.Net.Compilers verwiesen wird. Wenn Sie keine bestimmte Version des Compilers verwenden möchten, entfernen Sie Verweise auf Microsoft.Net.Compilers. Stellen Sie andernfalls sicher, dass die Version des referenzierten Pakets ebenfalls 2.6 oder höher ist.

Versuchen Sie, den Fehlerprotokollpfad abzurufen, der in der Option csc.exe /errorlog angegeben ist. Die Option und der Pfad werden im Protokoll für die Buildaufgabe Roslyn Analyzers angezeigt. Sie können etwa wie /errorlog:F:\ts-services-123_work\456\s\Some\Project\Code\Code.csproj.sarif

Die C#-Compilerversion ist nicht aktuell genug.

Um die neuesten Versionen des C#-Compilers zu erhalten, wechseln Sie zu Microsoft.Net.Compilers. Um Ihre installierte Version zu erhalten, führen Sie csc.exe /version an einer Eingabeaufforderung aus. Stellen Sie sicher, dass Sie auf ein Microsoft.Net.Compilers NuGet-Paket verweisen, das Version 2.6 oder höher ist.

MSBuild- und VSBuild-Protokolle wurden nicht gefunden

Die Buildaufgabe Roslyn Analyzers muss Azure DevOps für das MSBuild-Protokoll aus der MSBuild-Buildaufgabe abfragen. Wenn die Analyseaufgabe unmittelbar nach der MSBuild-Aufgabe ausgeführt wird, ist das Protokoll noch nicht verfügbar. Platzieren Sie andere Vorgänge zwischen der MSBuild-Aufgabe und der Roslyn Analyzers-Aufgabe. Beispiele für andere Aufgaben sind BinSkim und Anti-Malware Scanner.

Nächste Schritte

Wenn Sie zusätzliche Unterstützung benötigen, steht der Microsoft Security Code Analysis Support montags bis freitags von 9:00 bis 17:00 Uhr pazifische Standardzeit zur Verfügung.

• Onboarding: Lesen Sie unsere Onboarding-Dokumentation

• Support: Senden Sie unser Team an Microsoft Security Code Analysis Support