Auflösen eines blockierten Hosts in einem Dependabot-Updateauftrag

Diagnostizieren Sie einen Aktualisierungsauftrag, der fehlschlägt, weil Dependabot keinen Host erreichen konnte, und lassen Sie den benötigten Host zu.

In diesem Artikel

Jeder Dependabot Updateauftrag wird hinter einem HTTP/HTTPS-Proxy ausgeführt. Der Proxy überprüft den Host jeder ausgehenden Anforderung anhand einer Zulassungsliste für den Ausgang. Sie blockiert Anforderungen an Hosts, die nicht darin enthalten sind.

Dadurch wird das Risiko reduziert, dass ein schädliches Abhängigkeits- oder Buildskript Repositoryinhalte oder Registrierungsanmeldeinformationen an ein nicht genehmigtes Ziel senden kann. Es verhindert nicht, dass Daten an einen zulässigen oder kompromittierten Host gesendet werden.

Die meisten Aufträge sind nicht betroffen. Die Allowlist umfasst bereits öffentliche Registrys, Mirrors, CDNs und Download-Hosts für unterstützte Ökosysteme sowie die Infrastruktur von GitHub. Für einen Job konfigurierte und referenzierte Registrys sind ebenfalls automatisch zugelassen.

Eine Registry gilt nur dann als konfiguriert, wenn Sie sie unter dem Top-Level-Schlüssel registries in Ihrer dependabot.yml-Datei deklarieren. Die Definition einer Registry ausschließlich in einer für das jeweilige Ökosystem nativen Konfigurationsdatei, z. B. .npmrc, nuget.config, pip.conf oder Mavens settings.xml, ermöglicht nicht die Angabe des Hosts. Der Paket-Manager liest die Registrierung aus dieser Datei und versucht, sie zu erreichen, aber der Proxy blockiert die Anforderung.

Identifizieren einer blockierten Anforderung in Auftragsprotokollen

Wenn der Proxy eine Anfrage blockiert, gibt er 403 Forbidden an den Updateauftrag zurück. Der Fehler wird in der Regel als Netzwerk- oder Authentifizierungsfehler vom Paket-Manager angezeigt. Überprüfen Sie die Proxyzeilen im Auftragsprotokoll, um die Ursache zu bestätigen. Informationen zum Öffnen von Auftragsprotokollen finden Sie unter Anzeigen von Dependabot-Auftragsprotokollen.

Eine blockierte Anforderung sieht wie folgt aus:

proxy | 2026/09/24 20:58:15 [052] GET https://packages.example.com:443/v2/my-package/tags/list
proxy | 2026/09/24 20:58:15 [052] * egress not allowlisted packages.example.com
proxy | 2026/09/24 20:58:15 [052] 403 https://packages.example.com:443/v2/my-package/tags/list
proxy | 2026/09/24 20:58:15 [052] Remote response: Forbidden

Zeilen vom Proxy sind mit dem Präfix proxy | versehen, und [052] ist die Anfragenummer, die die Zeilen für eine einzelne Anfrage gruppiert. Die egress not allowlisted Zeile benennt den genauen Host, bei dem die Überprüfung fehlgeschlagen ist. Verwenden Sie diesen Host, um zu entscheiden, was als Nächstes zu tun ist.

Wie Hosts zugelassen werden

Für jede Aufgabe sind zwei unabhängige Gruppen von Hosts erlaubt.

Standardhosts umfassen öffentliche Registrierungen, Spiegel, CDNs und Downloadhosts für unterstützte Ökosysteme. Sie umfassen auch GitHub- und Dependabot-Infrastruktur. GitHub verwaltet diese Liste im dependabot/proxy Repository und gilt für jeden Auftrag.

Job-spezifische Hosts stammen aus Registrys, die für einen bestimmten Job konfiguriert sind. Deklarieren Sie eine Registry unter dem Top-Level-Schlüssel registries in Ihrer dependabot.yml-Datei und verweisen Sie in einem updates-Eintrag darauf. Der Host der Registry ist dann für diesen Job erlaubt, ohne die Standardeinstellungen zu ändern.

Deklarieren Sie die Registrierung, auch wenn sie anonymen Zugriff zulässt. Es ist die Deklaration in dependabot.yml, nicht das Vorhandensein von Anmeldeinformationen, wodurch der Host erreichbar ist.

Diese Aufteilung bestimmt, wo ein blockierter Host gehört.

Hinzufügen eines Hosts zu den Standardeinstellungen

Wenn es sich bei einem blockierten Host um ein öffentliches Registry, einen Spiegelserver, ein CDN oder einen Download-Host handelt, können Sie dessen Aufnahme vorschlagen, indem Sie einen Pull Request gegen dependabot/proxy eröffnen. Eine genehmigte Ergänzung gilt für jeden Dependabot-Updateauftrag, nicht nur für die Aufträge in Ihrer Organisation.

Das Repository bietet einen Agent-Skill, der Copilot durch diesen Prozess führt – von der Überprüfung, ob der Host zu den Standardwerten gehört, bis hin zum Öffnen des Pull Requests. Wenn Sie im Repository dependabot/proxy arbeiten, teilen Sie Copilot mit, dass ein Host blockiert ist, bitten Sie darum, einen Host zur Zulassungsliste hinzuzufügen, oder fügen Sie die blockierten Zeilen aus Ihrem Jobprotokoll ein. Zum Beispiel „repo.example.org ist blockiert“ oder „bitte foo.bar.com zur Zulassungsliste hinzufügen“. Führen Sie andernfalls die folgenden Schritte aus.

  1. Vergewissern Sie sich, dass der Host in die Standardwerte gehört. Es muss sich um einen öffentlichen Host handeln, den die Aufträge anderer Benutzer legitim benötigen könnten, nicht eine, die für Ihre Organisation spezifisch ist. Überprüfen Sie, wer den Host steuert und warum ein unterstütztes Ökosystem Darauf zugreifen muss. Wenn der Host für Ihre Organisation spezifisch ist, konfigurieren Sie ihn stattdessen in Ihrer dependabot.yml Datei.
  2. Überprüfen Sie den Host aus Ihren Auftragsprotokollen. Notieren Sie sich den genauen Host, der in der egress not allowlisted Zeile benannt ist. Registrierungen leiten häufig Downloads an einen separaten Speicher- oder CDN-Host um, daher überprüfen Sie, ob mehrere Hosts blockiert wurden.
  3. Öffnen Sie eine Pull-Anforderung , um den genauen Host zum entsprechenden Abschnitt hinzuzufügen internal/handlers/egress_allowlist_defaults.yaml. Fügen Sie eine kurze Notiz ein, in der erläutert wird, wer den Host steuert und was er dient. Folgen Sie den Kommentaren in der Datei, um den richtigen Abschnitt auszuwählen und dessen Konventionen anzuwenden. Ein Betreuer überprüft die Änderung.

Wenn Sie nicht sicher sind, ob ein blockierter Host den Standardwerten hinzugefügt oder in Ihrer dependabot.yml Datei konfiguriert werden soll, fragen Sie im dependabot/proxy Repository.