Einrichten der Abhängigkeitsüberprüfung

Die Abhängigkeitsüberprüfung in GitHub Advanced Security für Azure DevOps erkennt die Open-Source-Komponenten, die in Ihrem Quellcode verwendet werden, und damit verbundene Sicherheitsrisiken. Alle gefundenen Sicherheitsrisiken aus Open-Source-Komponenten werden als Warnung gekennzeichnet. Sie benötigen entweder GitHub Advanced Security für Azure DevOps oder, wenn Sie die eigenständige Oberfläche verwenden, GitHub Code Security für Azure DevOps aktiviert.

GitHub Advanced Security für Azure DevOps funktioniert mit Azure Repos. Informationen zur Verwendung von GitHub Advanced Security mit GitHub-Repositorys finden Sie unter GitHub Advanced Security.

Voraussetzungen

Kategorie

Anforderungen

Erlaubnisse

– Um eine Zusammenfassung aller Warnungen für ein Repository anzuzeigen: Beitragsberechtigungen für das Repository. - Um Warnhinweise in der erweiterten Sicherheit zu verwerfen: Projektadministrator Berechtigungen. – So verwalten Sie Berechtigungen in Advanced Security: Mitglied der Gruppe "Project Collection Administrators" oder Berechtigung "Advanced Security: Einstellungen verwalten" auf „Zulassen“ gesetzt.

Weitere Informationen zu Erweiterten Sicherheitsberechtigungen finden Sie unter "Verwalten erweiterter Sicherheitsberechtigungen".

Informationen zur Abhängigkeitsüberprüfung

Die Abhängigkeitsüberprüfung generiert eine Warnung für jede direkte oder transitive Open-Source-Komponente, die eine Sicherheitsanfälligkeit aufweist und von der Ihr Code abhängt. Direkte Sicherheitsrisiken sind die Bibliotheken, die Ihr Code direkt verwendet. Transitive Abhängigkeiten sind die Bibliotheken oder andere Software, die direkte Abhängigkeiten verwenden.

Informationen zur Erkennung von Abhängigkeiten

Eine neue Momentaufnahme Ihrer Komponenten wird gespeichert, wenn sich die Abhängigkeitsdiagramm für ein Repository ändert, und nach einer Pipeline, die die Abhängigkeitsüberprüfungsaufgabe enthält, ausgeführt wird.

Für jede erkannte gefährdete Komponente werden die Komponente und die Sicherheitslücke im Buildprotokoll aufgelistet und als Warnung auf der Registerkarte „Advanced Security“ (Erweiterte Sicherheit) angezeigt. Nur von GitHub überprüfte und zur GitHub Advisory Database hinzugefügte Hinweise generieren eine Warnung der Abhängigkeitsüberprüfung. Das Buildprotokoll enthält einen Link zur jeweiligen Warnung zur weiteren Untersuchung. Weitere Informationen zu den Warnungsdetails finden Sie unter „Beheben von Warnungen der Abhängigkeitsüberprüfung“.

Das Buildprotokoll enthält auch grundlegende Informationen zu jedem erkannten Sicherheitsrisiko. Diese Details umfassen den Schweregrad, die betroffene Komponente, den Titel der Sicherheitsanfälligkeit und die zugehörige CVE.

Eine Liste der unterstützten Komponentenökosysteme und -versionen finden Sie unter Unterstützte Paketökosysteme.

Erfahren Sie mehr über Abhängigkeitsscanbenachrichtigungen

Die Registerkarte „Advanced Security“ in Repos in Azure DevOps ist der Hub zum Anzeigen Ihrer Sicherheitswarnungen. Er zeigt standardmäßig Warnungen der Abhängigkeitsüberprüfung an. Sie können nach Branch, Pipeline, Paket und Schweregrad filtern. Sie können eine Warnung auswählen, um weitere Details zu erhalten, einschließlich Anleitungen zur Behebung. Zurzeit werden im Warnungshub keine Warnungen für die abgeschlossene Überprüfung von PR-Verzweigungen angezeigt.

Wenn ein anfälliges Paket in Ihrem Repository erkannt wird, umfasst das Beheben von Warnungen der Abhängigkeitsüberprüfung in der Regel ein Upgrade auf eine höhere Paketversion oder das Entfernen eines problematischen Pakets. Diese Empfehlung gilt sowohl für direkte als auch für transitive (oder indirekte) Abhängigkeiten. Die Standardansicht auf der Registerkarte „Advanced Security“ sind aktive Warnungen für den Standardbranch für Ihr Repository.

Es gibt keine Auswirkungen auf Ergebnisse, wenn Pipelines oder Verzweigungen umbenannt werden – es kann bis zu 24 Stunden dauern, bis der neue Name angezeigt wird.

Der Status einer Warnung wird automatisch in Closed aktualisiert, wenn die anfällige Komponente im neuesten Build für Pipelines, in denen der Task für Abhängigkeitsüberprüfung installiert ist, nicht mehr erkannt wird. Um Ihre aufgelösten Warnungen anzuzeigen, verwenden Sie den State-Filter in der Hauptsymbolleiste und wählen Closed aus.

Wenn Sie Advanced Security für Ihr Repository deaktivieren, verlieren Sie den Zugriff auf die Ergebnisse auf der Registerkarte „Advanced Security“ und den Buildtask. Die Buildaufgabe schlägt nicht fehl, aber alle Ergebnisse von Builds, die mit der Aufgabe ausgeführt werden, während die erweiterte Sicherheit deaktiviert ist, werden ausgeblendet und nicht beibehalten.

Warnungsdetails

Sie können auch detaillierte Informationen zu einer Warnung anzeigen, indem Sie auf eine bestimmte Warnung und eine Anleitung zur Behebung klicken.

`Section`	Erklärung
Empfehlung	Der Empfehlungstext stammt direkt von unserem Anbieter für Sicherheitsrisikodaten, der GitHub Advisory Database. In der Regel wird in der Empfehlung ein Upgrade der identifizierten Komponente auf eine nicht für Sicherheitsrisiken anfällige Version vorgeschlagen.
Standort	Im Abschnitt "Speicherorte " werden die Pfade beschrieben, in denen die Abhängigkeitsscanaufgabe die gefährdete Komponente ermittelt. Wenn die Datei von der zugrunde liegenden Buildüberprüfung in eine committete Datei in der Quelle aufgelöst werden kann, wird die Karte „Locations“ als klickbarer Link angezeigt. Wenn eine Datei als Teil eines Buildvorgangs (z. B. ein Buildartefakt) generiert wurde, kann auf den Link nicht geklickt werden. Überprüfen Sie die Buildprotokolle, um besser zu verstehen, wie die Komponente in den Build gelangt ist.
BESCHREIBUNG	Die Beschreibung wird in der GitHub-Empfehlungsbeschreibung bereitgestellt.

Erkennungen

Die auf der Registerkarte Detections (Erkennungen) aufgeführten Pipelines sind die Pipelines, in denen die anfällige Komponente gefunden wurde. Jede Zeile enthält den neuesten Build der betroffenen Pipeline und das Datum, an dem das Paket zum ersten Mal eingeführt wurde. Wenn das anfällige Paket in einigen Pipelines, aber nicht in allen Pipelines behoben ist, werden teilweise feste Zeilen angezeigt.

Sobald eine Warnung aufgelöst wird, wechselt die Warnung automatisch in den Closed Zustand, und die neueste Ausführungspipeline auf der Registerkarte "Erkennungen" zeigt ein grünes Häkchen an, was bedeutet, dass Code, der die aktualisierte Komponente enthält, in dieser Pipeline ausgeführt wurde:

severity

Die GitHub Advisory Database stellt eine CVSS-Bewertung bereit, die dann gemäß den folgenden Richtlinien in einen niedrigen, mittleren, hohen oder kritischen Schweregrad für eine Warnung übersetzt wird:

CVSS-Bewertung	severity
1,0 < Punktzahl < 4,0	Niedrig
4.0 < Punkt < 7,0	Mittel
7,0 < Punkt < 9,0	Hoch
Score >= 9,0	Kritisch

Ermitteln von Details

Zwei Abschnitte finden sich häufig unter Finding Details (Suchen nach Details): anfälliges Paket und Stammabhängigkeit. Das anfällige Paket ist die potenziell für Sicherheitsrisiken anfällige Komponente. Der Abschnitt „root dependency“ (Stammabhängigkeit) enthält Komponenten der obersten Ebene, die für die Abhängigkeitskette verantwortlich sind, die zu einem Sicherheitsrisiko führt.

Wenn auf das anfällige Paket nur als direkte Abhängigkeit verwiesen wird, wird nur der Abschnitt "anfälliges Paket" angezeigt.

Wenn auf das anfällige Paket sowohl als direkte als auch transitive Abhängigkeit verwiesen wird, wird das Paket sowohl im Abschnitt "anfälliges Paket" als auch im Abschnitt "Stammabhängigkeit" angezeigt.

Wenn auf das anfällige Paket nur als transitive Abhängigkeit verwiesen wird, wird das Paket im Abschnitt "anfälliges Paket" angezeigt, und die Stammabhängigkeiten, die auf das anfällige Paket verweisen, werden im Abschnitt "Stammabhängigkeit" angezeigt.

Verwalten von Warnungen der Abhängigkeitsüberprüfung

Anzeigen von Warnungen für ein Repository

Standardmäßig werden auf der Warnungsseite Ergebnisse der Abhängigkeitsüberprüfung für den Standardbranch des Repositorys angezeigt.

Die Status einer Warnung gibt den Status für den Standardbranch und die zuletzt ausgeführte Pipeline an, auch wenn die Warnung für andere Branches und Pipelines vorhanden ist.

Beheben von Warnungen der Abhängigkeitsüberprüfung

Eine direkte Abhängigkeit ist eine Komponente, die in Ihrem Repository vorhanden ist. Eine transitive oder indirekte Abhängigkeit ist eine Komponente, die von einer direkten Abhängigkeit verwendet wird. Ihr Projekt ist weiterhin für Sicherheitsrisiken anfällig, unabhängig davon, ob die Sicherheitsanfälligkeit in einer direkten oder transitiven Abhängigkeit gefunden wird.

Die Behebung einer anfälligen transitiven Abhängigkeit erfolgt in der Regel durch explizites Überschreiben der Version der anfälligen Komponente, die für jede identifizierte direkte Abhängigkeit verwendet wird. Sobald die Stammabhängigkeiten ihre Verwendung der anfälligen Komponente auf eine sichere Version aktualisieren, können Sie jede Stammabhängigkeit anstelle mehrerer einzelner Außerkraftsetzungen aktualisieren.

Aktualisieren von Abhängigkeiten für Yarn/npm

Angenommen, dieses Paket weist zwei Sicherheitsrisiken auf. Ein Sicherheitsrisiko bezieht sich auf axios, eine direkte Abhängigkeit, und ein Sicherheitsrisiko auf acorn, eine transitive Abhängigkeit (auch als indirekte Abhängigkeit oder Abhängigkeit der Abhängigkeit bezeichnet).

{
 "name": "my-package",
 "version": "1.0.0",
 "dependencies": {
   "axios": "0.18.0",
   "eslint": "5.16.0",
 }
}

Die aktuelle Version von axios weist ein Denial-of-Service-Sicherheitsrisiko (DoS-Sicherheitsrisiko) mit der Empfehlung auf , ein Update auf v0.18.1 oder höher auszuführen. Da es sich um eine direkte Abhängigkeit handelt, haben Sie die Kontrolle über die Version von axios, die Sie verwenden. Sie müssen lediglich die Version von axios aktualisieren, die Sie pullen. Die aktualisierte Datei package.json sieht in etwa wie folgt aus:

{
  "name": "my-package",
  "version": "1.0.0",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0",
  }
}

Jetzt hängt die in der eslint angezeigte Version von package.json von einer Version von acorn ab, die eine reguläre Ausdruck Dienstverweigerung (Re-DoS)-Schwachstelle ist, wobei eine Empfehlung besteht, auf Version 5.7.4, 6.4.1, 7.1.1 oder höher zu aktualisieren. Wenn Sie eine Warnung vom Abhängigkeitsüberprüfungstool erhalten, sollte sie die Stammabhängigkeit nennen, die die für Sicherheitsrisiken anfällige Abhängigkeit erfordert.

Garn

Wenn Sie Yarn verwenden, können Sie „yarn why“ verwenden, um die vollständige Abhängigkeitskette zu ermitteln.

> $ yarn why acorn
 yarn why v1.22.4
 [1/4] Why do we have the module "acorn"...?
 [2/4] Initialising dependency graph...
 [3/4] Finding dependency...
 [4/4] Calculating file sizes...
 => Found "acorn@6.4.0"
 info Reasons this module exists
   - "eslint#espree" depends on it
   - Hoisted from "eslint#espree#acorn"
 info Disk size without dependencies: "1.09MB"
 info Disk size with unique dependencies: "1.09MB"
 info Disk size with transitive dependencies: "1.09MB"
 info Number of shared dependencies: 0
 Done in 0.30s.

Die vollständige Abhängigkeitskette ist eslint>espree>acorn. Sobald Sie die Abhängigkeitskette kennen, können Sie ein weiteres Feature von Yarn (selektive Abhängigkeitsauflösungen) verwenden, um die Version von acorn zu überschreiben, die verwendet wird.

Verwenden Sie das Auflösungsfeld in package.json, um eine Versionsüberschreibung zu definieren. Es werden drei verschiedene Methoden gezeigt, um ein Paket zu überschreiben, in der Reihenfolge von der schlechtesten bis hin zur besten:

{
  "name": "yarn-resolutions",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0"
  },
  "resolutions": {
    // DO NOT USE!
    "**/acorn": "6.4.1",
    // BETTER
    "eslint/**/acorn": "6.4.1",
    // BEST
    "eslint/espree/acorn": "6.4.1"
  }
}

Die Verwendung des **/acorn-Musters überschreibt alle Verwendungen des acorn-Pakets über alle Abhängigkeiten hinweg. Es ist gefährlich und verursacht zur Laufzeit Fehler, daher haben wir es in Yarn v2 entfernt.

Die Verwendung des eslint/**/acorn-Musters überschreibt alle Verwendungen des acorn-Pakets unter dem eslint-Paket und in allen Paketen, von denen eine Abhängigkeit besteht. Dies ist sicherer als das Überschreiben des Pakets für alle Abhängigkeiten, aber es besteht immer noch ein gewisses Risiko, wenn das Abhängigkeitsdiagramm für ein Paket groß ist. Dieses Muster wird empfohlen, wenn es viele Unterpakete gibt, die ein anfälliges Paket verwenden und das Definieren von Außerkraftsetzungen für einzelne Teilpakete nicht praktikabel ist.

Die Verwendung des Musters eslint/espree/acorn überschreibt nur die Verwendung von acorn im espree-Paket im eslint-Paket. Es zielt speziell auf die anfällige Abhängigkeitskette ab und ist die empfohlene Methode, Paketversionen zu überschreiben.

npm

Wenn Sie npm 8.3 oder höher verwenden, können Sie das Feld overrides (Außerkraftsetzungen) in Ihrer Datei „package.json“ verwenden.

Fügen Sie eine Außerkraftsetzung hinzu, wenn Sie bestimmte Änderungen an transitiven Abhängigkeiten vornehmen müssen. Beispielsweise müssen Sie die Version einer Abhängigkeit mit einem bekannten Sicherheitsproblem außer Kraft setzen, eine vorhandene Abhängigkeit durch eine Verzweigung ersetzen oder sicherstellen, dass die gleiche Version eines Pakets überall verwendet wird.

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0"
  },
   "overrides":{
       "eslint": {
        "espree": {
          "acorn": "6.4.1"
        }
    }
   }
}

Das gezeigte Überschreibungsbeispiel zeigt, wie npm die Anweisung „überschreibe nur die Verwendung von acorn im espree-Paket im eslint-Paket“ ausdrückt. Dies zielt speziell auf die anfällige Abhängigkeitskette ab und ist die empfohlene Methode zum Überschreiben von Paketversionen. Außerkraftsetzungen sind ein natives Feature von npm. Es bietet eine Möglichkeit, ein Paket in Ihrer Abhängigkeitsstruktur durch eine andere Version oder vollständig durch ein anderes Paket zu ersetzen.

Nachdem Sie Ihre Außerkraftsetzungen festgelegt haben, müssen Sie ihre Datei package-lock.json und node_modules löschen und npm install erneut ausführen.

Normalerweise legen Sie für ein Paket, auf das Sie direkt angewiesen sind, keine Überschreibung fest, es sei denn, sowohl die Abhängigkeit als auch die Überschreibung haben genau dieselbe Spezifikation. Angenommen, axios: "0.18.0" ist anfällig, und wir möchten auf axios: "0.19.2" umsteigen. Ändern Sie die Abhängigkeitsversion direkt, anstatt eine Außerkraftsetzung zu verwenden.

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.18.0"
  },
  "overrides": {
    // BAD, will throw an EOVERRIDE error
    // "axios": "0.19.2",
  }
}

Aktualisieren Sie die Version der Abhängigkeit, ohne eine Außerkraftsetzung festzulegen:

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2"
  }
}

Aktualisieren von Abhängigkeiten für Maven

Der Mechanismus zur Auflösung von Abhängigkeiten ist nicht so ausgeklügelt wie der in Yarn verwendete Mechanismus. Daher kann nur eine einzelne Version einer Abhängigkeit in einem Projekt vorhanden sein. Um dieses Problem zu beheben, verwendet Maven einen Algorithmus für "nächste Gewinne". Das heißt, es wird die Version der Abhängigkeit verwendet, die Ihrem Projekt in der Abhängigkeitsstruktur am nächsten liegt.

Beispielsweise verfügen Sie über das folgende Abhängigkeitsdiagramm:

your-project --- A:1.0.0 --- B:2.0.0
      \
       \__ B:1.0.0

your-project hängt von A:1.0.0 ab, was wiederum von B:2.0.0 abhängt, aber Ihr Projekt weist auch eine direkte Abhängigkeit von B:1.0.0 auf. Sie haben also zwei unterschiedliche Versionen von Abhängigkeit B in Ihrem Abhängigkeitsdiagramm, aber Version 1.0.0 der Abhängigkeit B gewinnt, da es für Ihr Projekt "am nächsten" ist.

In einigen Fällen kann dieses Szenario funktionieren, wenn die Versionen kompatibel sind. Wenn A:1.0.0 jedoch von einer Funktion von B abhängt, das nur in Version 2.0.0 verfügbar ist, funktioniert dieses Verhalten nicht. In einem schlimmsten Fall kann dieses Projekt trotzdem kompiliert werden, schlägt aber zur Laufzeit fehl.

Werfen wir einen Blick auf ein Beispiel aus der Praxis.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.microsoft.customer360</groupId>
  <artifactId>maven-dependencies</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>maven-dependencies</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.jaxrs</groupId>
      <artifactId>jackson-jaxrs-json-provider</artifactId>
      <version>2.10.3</version>
    </dependency>
</project>

Angenommen, die Version von com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider, von der Sie abhängig sind, hängt von einer Version von com.fasterxml.jackson.core:jackson-databind ab, die ein Sicherheitsrisiko bei der Deserialisierung von nicht vertrauenswürdigen Daten aufweist.

Sie können diese Abhängigkeit mithilfe des Maven-Abhängigkeits-Plug-Ins überprüfen. In diesem Fall würden Sie mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind ausführen und die folgende Ausgabe erhalten:

> $ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
 [INFO] Scanning for projects...
 [INFO]
 [INFO] ------------< com.microsoft.customer360:maven-dependencies >------------
 [INFO] Building maven-dependencies 1.0-SNAPSHOT
 [INFO] --------------------------------[ jar ]---------------------------------
 [INFO]
 [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-dependencies ---
 [INFO] com.microsoft.customer360:maven-dependencies:jar:1.0-SNAPSHOT
 [INFO] \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.10.3:compile
 [INFO]    \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.10.3:compile
 [INFO]       \- com.fasterxml.jackson.core:jackson-databind:jar:2.10.3:compile
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD SUCCESS
 [INFO] ------------------------------------------------------------------------
 [INFO] Total time:  0.928 s
 [INFO] Finished at: 2020-04-27T14:30:55+02:00
 [INFO] ------------------------------------------------------------------------

Überprüfen Sie zunächst, ob es eine neue Version von com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider gibt, die nicht von einer anfälligen Version von com.fasterxml.jackson.core:jackson-databind abhängig ist. Wenn dies der Fall ist, können Sie ein Upgrade von com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider durchführen und dann aufhören. Andernfalls überschreiben Sie die Version von com.fasterxml.jackson.core:jackson-databind.

Wie im Codeausschnitt gezeigt, gilt bei der Verwendung von Maven das Prinzip 'der Nächste gewinnt', sodass die Lösung darin besteht, eine direkte Abhängigkeit zu com.fasterxml.jackson.core:jackson-databind hinzuzufügen, um die Sicherheitsanfälligkeit zu beheben.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.microsoft.customer360</groupId>
  <artifactId>maven-dependencies</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>maven-dependencies</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.jaxrs</groupId>
      <artifactId>jackson-jaxrs-json-provider</artifactId>
      <version>2.10.3</version>
    </dependency>
    <!-- Dependency resolutions -->
    <!-- jackson-jaxrs-json-provider -->
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
      <version>2.9.10.4</version>
    </dependency>
  </dependencies>
</project>

Sie können überprüfen, ob die Auflösung funktioniert, indem Sie mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind erneut ausführen.

$ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
[INFO] Scanning for projects...
[INFO]
[INFO] ------------< com.microsoft.customer360:maven-dependencies >------------
[INFO] Building maven-dependencies 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-dependencies ---
[INFO] com.microsoft.customer360:maven-dependencies:jar:1.0-SNAPSHOT
[INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.9.10.4:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.827 s
[INFO] Finished at: 2020-04-27T14:32:42+02:00
[INFO] ------------------------------------------------------------------------

Es wird empfohlen, einen Kommentar in der Nähe der Abhängigkeitsauflösung hinzuzufügen, damit jeder, der später kommt, weiß, warum die Abhängigkeit vorhanden ist. Der Hinweis kann entfernt werden, sobald die Stammabhängigkeit die neue Version verwendet. Andernfalls akkumulieren Sie Abhängigkeiten.

In einem realen Projekt sollten Sie die Abhängigkeit so weit oben in der Kette wie möglich hinzufügen. Beispielsweise können Sie die Auflösung in der übergeordneten POM-Datei hinzufügen, anstatt sie in jeder POM-Projektdatei einzeln anzugeben.

Aktualisieren von Abhängigkeiten für NuGet

Der in NuGet verwendete Algorithmus zur Auflösung von Abhängigkeiten ähnelt Maven, da nur eine einzelne Version einer Abhängigkeit verwendet werden kann. NuGet heftet jedoch keine Abhängigkeitsversionen an.

Wenn Sie beispielsweise über eine Abhängigkeit <PackageReference Include="A" Version="1.2.3" /> verfügen, erwarten Sie möglicherweise, dass dieses Paket mit = 1.2.3 äquivalent ist, aber es bedeutet tatsächlich >= 1.2.3. Um eine genaue Version anzuheften, sollten Sie Version="[1.2.3]" verwenden. Weitere Informationen finden Sie in der Dokumentation zu Versionsbereichen von NuGet.

Zusätzlich zum standardmäßigen Bereichsverhalten stellt NuGet die niedrigste anwendbare Version wieder her, um einen Bereich abzudecken. Dieses Verhalten bedeutet, dass Sie in vielen Fällen einen Bereich definieren müssen.

Sehen wir uns dieses Beispielprojekt an, das eine Abhängigkeit von Microsoft.AspNetCore.App aufweist:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>NuGet.Dependencies</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.14" />
  </ItemGroup>
</Project>

Es hängt von einer Version von Microsoft.AspNetCore.Http.Connections ab, die anfällig für ein RCE-Sicherheitsrisiko (Remote Code Execution, Remotecodeausführung) ist.

Zunächst sollten Sie überprüfen, ob eine aktualisierte Version von Microsoft.AspNetCore.App vorhanden ist, die von einer neueren Version von Microsoft.AspNetCore.Http.Connections abhängt. Wenn dies der Fall ist, können Sie ein Upgrade von Microsoft.AspNetCore.App durchführen und dann aufhören. Andernfalls müssen Sie die Version davon Microsoft.AspNetCore.Http.Connections überschreiben, von der die Abhängigkeit besteht.

In NuGet ist keine zu „yarn why“ oder „mvn dependency:tree“ äquivalente Funktion integriert, daher ist die einfachste Möglichkeit zum Anzeigen der Abhängigkeitsstruktur häufig, nuget.org zu besuchen. Wenn Sie die NuGet-Seite für Microsoft.AspNetCore.Appbesuchen, sehen Sie, dass eine Abhängigkeit von Microsoft.AspNetCore.Http.Connectionsversion >= 1.0.4 && < 1.1.0 vorliegt. In einem NuGet-Versionsbereich ist die repräsentative Syntax [1.0.4,1.1.0).

Das RCE-Sicherheitsrisiko in Microsoft.AspNetCore.Http.Connections wurde in Version 1.0.15 behoben, sodass Sie den zu verwendenden Versionsbereich als [1.0.15, 1.1.0) überschreiben müssen.

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>NuGet.Dependencies</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.8" />
  </ItemGroup>

  <ItemGroup Label="Dependency Resolutions">
    <!-- Microsoft.AspNetCore.App -->
    <PackageReference Include="Microsoft.AspNetCore.Http.Connections" Version="[1.0.15,1.1.0)" />
  </ItemGroup>
</Project>

Es wird empfohlen, einen Kommentar in der Nähe der Abhängigkeitsauflösung hinzuzufügen, damit jeder, der später kommt, weiß, warum die Abhängigkeit vorhanden ist. Er kann entfernt werden, sobald die Stammabhängigkeit die neue Version verwendet. Andernfalls sammeln Sie Abhängigkeiten an.

Was geschieht, wenn kein Fix verfügbar ist?

Wenn kein bekannter Fix verfügbar ist, stehen die folgenden Optionen als andere Methoden zur Korrektur zur Verfügung, bis eine aktualisierte Komponente verfügbar ist:

• Beenden Sie die Verwendung der Komponente, und entfernen Sie sie aus Ihrem Code – diese Entfernung wird beim nächsten Build erkannt, wobei die Abhängigkeitsüberprüfungsaufgabe installiert ist.
• Tragen Sie selbst einen Fix für die Komponente bei. Wenn Ihre Organisation bestimmte Richtlinien für Open-Source-Beiträge enthält, befolgen Sie diese Richtlinien.
• Schließen Sie die Warnung. Warnungen ohne bekannten Fix können jedoch weiterhin eine Sicherheitsbedrohung für Ihre Organisation darstellen. Es wird empfohlen, eine Warnung nicht zu schließen, nur weil es keine bekannte Korrektur gibt.

Schließen von Warnungen der Abhängigkeitsüberprüfung

Führen Sie die folgenden Schritte aus, um eine Warnung zu entfernen:

1. Wechseln Sie zu der Benachrichtigung, die Sie schließen möchten, und wählen Sie sie aus.

2. Wählen Sie die Dropdownliste Close alert (Warnung schließen) aus.

3. Falls noch nicht ausgewählt, wählen Sie als Schließungsgrund entweder Risk accepted (Risiko akzeptiert) oder False positive (Falsch positiv) aus.

4. Fügen Sie dem Textfeld Comment (Kommentar) einen optionalen Kommentar hinzu.

5. Wählen Sie Close (Schließen) aus, um die Warnung zu übermitteln und zu schließen.

6. Der Warnungsstatus ändert sich aus Open (Offen) in Closed (Geschlossen) und zeigt Ihren Schließungsgrund an.

   

Mit dieser Aktion wird die Warnung in allen Zweigstellen zurückgesetzt. Andere Zweige, die dieselbe Sicherheitslücke enthalten, werden ebenfalls geschlossen. Alle Warnungen, die zuvor geschlossen wurden, können manuell erneut geöffnet werden.

Verwalten von Warnungen der Abhängigkeitsüberprüfung bei Pull Requests

Wenn Warnungen für neue Codeänderungen in einem Pull-Request erstellt werden, wird die Warnung als Anmerkung im Kommentarabschnitt des Übersicht-Tabs des Pull-Requests gemeldet und als Warnung auf der Registerkarte Advanced Security. Für den Pull-Request-Zweig ist ein neuer Eintrag im Branch-Auswahlmenü verfügbar.

Sie können das betroffene Paketmanifest und eine Zusammenfassung der Suche anzeigen und die Anmerkung im Abschnitt „Übersicht“ auflösen.

Um Pull Request-Warnungen zu schließen, müssen Sie zur Warnungsdetailansicht navigieren, um die Warnung zu schließen und die Anmerkung aufzulösen. Andernfalls löst einfach das Ändern des Kommentarstatus (1) die Anmerkung auf, schließt oder korrigiert die zugrunde liegende Warnung nicht.

Um den gesamten Satz von Ergebnissen für Ihren Pull Request-Branch anzuzeigen, navigieren Sie zu Repos>Advanced Security, und wählen Sie den Pull Request-Branch aus. Wenn Sie in der Anmerkung weitere Details anzeigen (2) auswählen, gelangen Sie zur Warnungsdetailansicht auf der Registerkarte "Erweiterte Sicherheit".

Tipp

Anmerkungen werden nur erstellt, wenn die betroffenen Zeilen des Codes in der Pull-Request-Differenz zum Ziel-Branch der Pull-Request völlig eindeutig sind.

Verwandte Artikel

• Informationen zu unterstützten Paketökosystemen
• Fehlerbehebung bei der Abhängigkeitsscannen
• Geheimnisscannen einrichten
• Weitere Informationen zu Advanced Security