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.
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.json, npm-shrinkwrap.json, lerna.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, die Abhängigkeitsstruktur anzuzeigen, 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 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 Buildvorgang erkannt, wenn der Task „Abhängigkeitsüberprüfung“ 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:
- Navigieren Sie zu der Warnung, die Sie schließen möchten, und wählen Sie sie aus.
- Wählen Sie die Dropdownliste Close alert (Warnung schließen) aus.
- Falls noch nicht ausgewählt, wählen Sie als Schließungsgrund entweder Risk accepted (Risiko akzeptiert) oder False positive (Falsch positiv) aus.
- Fügen Sie dem Textfeld Comment (Kommentar) einen optionalen Kommentar hinzu.
- Wählen Sie Close (Schließen) aus, um die Warnung zu übermitteln und zu schließen.
- 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.
Problembehandlung der Abhängigkeitsüberprüfung
Timeout des Abhängigkeitsüberprüfungstasks
Die Standardzeit für die Ausführung des Abhängigkeitsüberprüfungstasks, bevor ein Timeout auftritt, beträgt 300 Sekunden (5 Minuten). Wenn bei dem Task vor seinem Abschluss ein Timeout auftritt, können Sie ein DependencyScanning.Timeout für eine Pipelinevariable festlegen, das ein Integer erwartet, das die Sekunden darstellt, z. B. DependencyScanning.Timeout: 600. Angaben unter dem Standardtimeout von 300 Sekunden haben keine Auswirkung.
Um diese Variable zu verwenden, fügen Sie sie als Pipelinevariable hinzu DependencyScanning.Timeout :
- task: AdvancedSecurity-Dependency-Scanning@1
- env:
DependencyScanning.Timeout: 600
Break-Glass-Szenario für Buildtask
Wenn der Buildtask für die Abhängigkeitsüberprüfung eine erfolgreiche Ausführung Ihrer Pipeline blockiert und Sie den Buildtask dringend überspringen müssen, können Sie eine Pipelinevariable DependencyScanning.Skip: true festlegen.
Berechtigungen für Abhängigkeitsüberprüfungsaufgaben
Die Buildaufgabe zum Überprüfen von Abhängigkeiten verwendet die Pipelineidentität, um die Advanced Security REST-APIs aufzurufen. Standardmäßig haben Pipelines im selben Projekt Zugriff auf das Abrufen von Warnungen. Wenn Sie diese Berechtigungen aus dem Builddienstkonto entfernen oder über ein benutzerdefiniertes Setup verfügen (z. B. eine Pipeline, die in einem anderen Projekt als das Repository gehostet wird), müssen Sie diese Berechtigungen manuell erteilen.
Erteilen Sie die Advanced Security: View Alerts-Berechtigung für das in Ihrer Pipeline verwendete Builddienstkonto, für projektbezogene Pipelines [Project Name] Build Service ([Organization Name]) und für Sammlungs-bezogene Pipelines Project Collection Build Service ([Organization Name]).
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für