Dependabot erhält ein Versionsfeld: Aufzeichnung und Deployment unterscheiden
Am 20. Oktober 2026 ergänzte GitHub Dependabot-REST-Antworten um dependency.version_requirement. Damit lässt sich ein Sicherheitsticket besser einordnen. Der Wert ist jedoch kein Nachweis der momentan in Produktion installierten Version. Offizielle Funktion und vorgeschlagene Betriebsprüfung sollten getrennt bleiben.
Schwachstellenbereich und Repository-Wert getrennt halten
vulnerable_version_range beschreibt den betroffenen Bereich einer Meldung. Das neue Feld enthält die zuletzt für den Alert aufgezeichnete Version oder Bedingung. Paket, Ökosystem und manifest_path daneben aufbewahren. Eine Versionsbedingung ist keine einzelne installierte Version; eine entsprechende Beschriftung verhindert irreführende Sortierungen im Ticket.
Der Erkennungspfad bestimmt die Bedeutung
Bei Lockfiles ist es die aufgelöste Version, ohne Lockfile die Manifest-Version oder Bedingung, bei der dependency submission API die vom Build übermittelte aufgelöste Version. Einzelne Alerts, Repository-, Organisations- und Enterprise-Listen sowie dependabot_alert-Webhooks enthalten das Feld. Es ist auf github.com und Enterprise Cloud mit Datenresidenz verfügbar; Enterprise Server 3.24 soll es enthalten. Ältere Server nicht ungeprüft einschließen.
null und Teilabdeckung sind normale Eingaben
Fehlende Werte sind null. Bei mehreren betroffenen Versionen kann ein einzelner aufgezeichneter Wert unvollständig sein; lange Bedingungen können gekürzt werden. Unser Vorschlag: Zeichenfolge und null erhalten, unbekannt niemals in sicher umdeuten und fehlende Werte alter Tickets sichtbar lassen. Gleiche Alert-Anzahlen beweisen keine vollständigen Versionsdaten.
Die Integration mit repräsentativen Alerts prüfen
Bereinigte Antwort, Erfassungszeit, Alert-ID und Manifest-Pfad gemeinsam dokumentieren. Lockfile-Version, Manifest-Bedingung und null bis in die Ticketansicht verfolgen. Webhooks und Listen anhand Repository und Alert-ID abgleichen, damit keine Duplikate entstehen. Berechtigungen anhand des jeweiligen Endpunkts prüfen; dies ist ein Betriebsvorschlag, keine neue automatische Reparaturfunktion.
Für den aktuellen Deployment-Stand sind eigene Build- und Deployment-Belege nötig. Nach einem Update Tests ausführen und Alert-Status erneut lesen. Die neue Angabe spart möglicherweise Ermittlungsarbeit, ersetzt aber keine Release-Prüfung. Entscheidend ist, ob der Bearbeiter Bedingung, unbekannten Wert und repräsentative Version unterscheiden kann.
Offizielle Quellen
GitHub Changelog · Dependency versions
GitHub Docs · Dependabot alerts REST API
Geprüft am 21. Oktober 2026. Eine Alert-Antwort mit der Versionsanzeige im zugehörigen Ticket vergleichen.