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.

GitHub Advanced Security für Azure DevOps funktioniert mit Azure Repos. Wenn Sie GitHub Advanced Security mit GitHub-Repositorys verwenden möchten, lesen Sie GitHub Advanced Security.

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 immer dann gespeichert, wenn sich das Abhängigkeitsdiagramm für ein Repository ändert. Danach wird eine Pipeline ausgeführt, die den Task zum Überprüfen der Abhängigkeiten enthält und neuen Code erstellt (anders ausgedrückt: ein neuer Commit).

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.

Unterstützte Paket-Ökosysteme

Die Abhängigkeitsüberprüfung unterstützt sowohl direkte als auch transitive Abhängigkeiten für alle unterstützten Paketökosysteme.

Paket-Manager	Languages	Unterstützte Formate
Cargo	Rust	Cargo.toml, Cargo.lock
CocoaPods	Swift	Podfile.lock
Go-Module	Go	go.mod, go.sum
Gradle	Java	*.lockfile
Maven	Java	pom.xml
npm	JavaScript	package-lock.json, , package.jsonnpm-shrinkwrap.jsonlerna.json
NuGet	C#	*.packages.config, *.project.assets*.csproj
pip	Python	setup.py, requirements.txt
pnpm	JavaScript	package.json
RubyGems	Ruby	Gemfile.lock
Yarn	JavaScript	package.json

Informationen zu Warnungen der Abhängigkeitsüberprüfung

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 hat keine Auswirkungen auf die Ergebnisse, wenn Pipelines oder Branches 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. Der Buildtask schlägt nicht fehl, aber alle Ergebnisse von Builds, die mit dem Task ausgeführt werden, während Advanced Security 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 Locations (Speicherorte) werden die Pfade beschrieben, in denen der Task der Abhängigkeitsüberprüfung die verwendete für Sicherheitsrisiken anfällige Komponente ermittelt hat. 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 behoben wurde, aber nicht in allen, werden teilweise gelöste Zeilen angezeigt.

Nachdem eine Warnung aufgelöst wurde, wechselt die Warnung automatisch in den Status Closed, und die zuletzt ausgeführte Pipeline auf der Registerkarte „Detections“ 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	Schweregrad
1.0 < Score < 4.0	Niedrig
4.0 < Score < 7.0	Mittel
7.0 < Score < 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 „vulnerable package“ (anfälliges Paket) angezeigt.

Wenn auf das anfällige Paket sowohl als direkte als auch als transitive Abhängigkeit verwiesen wird, wird das Paket sowohl im Abschnitt „vulnerable package“ als auch im Abschnitt „root dependency“ (Stammabhängigkeit) angezeigt.

Wenn auf das anfällige Paket nur als transitive Abhängigkeit verwiesen wird, wird das Paket im Abschnitt „vulnerable package“ angezeigt, und die Stammabhängigkeiten, die auf das anfällige Paket verweisen, werden im Abschnitt „root dependency“ angezeigt.

Verwalten von Warnungen der Abhängigkeitsüberprüfung

Anzeigen von Warnungen für ein Repository

Jede Person mit der Berechtigung „Mitwirkender“ für ein Repository kann eine Zusammenfassung aller Warnungen für ein Repository unter Repos>Advanced Security (Repositorys > Erweiterte Sicherheit) anzeigen.

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. Nachdem die Stammabhängigkeiten ihre Verwendung der anfälligen Komponente auf eine sichere Version aktualisiert haben, können Sie jede Stammabhängigkeit aktualisieren, anstatt mehrere einzelne Überschreibungen durchzuführen.

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",
  }
}

Nun hängt die Version von eslint in der gezeigten Datei package.json von einer Version von acorn ab, bei der es sich um ein RegEx-Denial-of-Service-Sicherheitsrisiko (ReDoS-Sicherheitsrisiko) mit der Empfehlung handelt, ein Update auf Version 5.7.4, 6.4.1, 7.1.1 oder höher auszuführen. 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.

Yarn

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 führt zur Laufzeit zu einem Fehler. Daher wurde 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 ggf. eine Außerkraftsetzung hinzufügen, um die Version einer Abhängigkeit mit einem bekannten Sicherheitsproblem zu ersetzen, eine vorhandene Abhängigkeit durch einen Fork zu ersetzen oder sicherzustellen, dass überall dieselbe Version eines Pakets 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.

Sie können keine Überschreibung für ein Paket festlegen, von dem Sie direkt abhängig sind, es sei denn, sowohl die Abhängigkeit als auch die Überschreibung selbst haben genau dieselbe Spezifikation. Angenommen, axios: "0.18.0" es ist anfällig, und wir möchten ein Upgrade auf axios: "0.19.2" durchführen. Ä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 „nearest wins“. 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 verfügen also über zwei verschiedene Versionen von Abhängigkeit B in Ihrem Abhängigkeitsdiagramm, aber Version 1.0.0 der Abhängigkeit B gewinnt, weil sie Ihrem 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. Im schlimmsten Fall kann dieses Projekt zwar 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 Codeschnipsel gezeigt, gilt bei Verwendung von Maven der „nearest wirs“, sodass die Lösung darin besteht, com.fasterxml.jackson.core:jackson-databind eine direkte Abhängigkeit hinzuzufügen, die das Sicherheitsrisiko behebt.

<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 Benutzer in Zukunft 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.Connections version >= 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 Benutzer in Zukunft 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

Um Warnungen in Advanced Security zu schließen, benötigen Sie die entsprechenden Berechtigungen. Standardmäßig verfügen nur Projektadministratoren über die Möglichkeit, Warnungen für Advanced Security zu schließen.

So schließen Sie eine Warnung:

1. Navigieren Sie zu der Warnung, 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.

Diese Aktion schließt die Warnung nur für Ihren ausgewählten Branch. Andere Branches, die möglicherweise dasselbe Sicherheitsrisiko enthalten, bleiben aktiv, bis anderweitig darauf reagiert wird. 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 einer Pullanforderung erstellt werden, wird die Warnung als Anmerkung im Kommentarabschnitt der Pullanforderung und als Warnung auf der Registerkarte Advanced Security gemeldet. Es gibt einen neuen Verzweigungsauswahleintrag für die Pullanforderungsverzweigung.

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 behebt die zugrunde liegende Warnung jedoch 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 Codezeilen im Vergleich zum Zielzweig der Pullanforderungsanforderung vollständig eindeutig sind.