Dependabot-Versionsupdates unterstützen jetzt den Agent Package Manager: nur Git-Abhängigkeiten mit Ref in apm.yml, keine Sicherheitsupdates, und GHES muss auf 3.24 warten

Am 3. November 2026 kündigte das GitHub-Changelog an, dass Dependabot-Versionsupdates jetzt den Agent Package Manager (APM) unterstützen, um Fähigkeiten, Prompts und Anweisungen von KI-Agenten aktuell zu halten. Dependabot öffnet Pull Requests, um unterstützte Git-Abhängigkeiten aus apm.yml zu aktualisieren, und erzeugt apm.lock.yaml neu, sofern die Datei vorhanden ist. Das Changelog sagt klar, dass diese Unterstützung Versionsupdates abdeckt, keine Sicherheitsupdates. Diese APM-Unterstützung erstellt keine Sicherheitsupdate-Pull-Requests; ob APM-Abhängigkeiten Sicherheitswarnungen auslösen können, geht aus den Quellen nicht hervor. Dependabot prüft unterstützte Abhängigkeiten nach dem eingestellten Zeitplan auf neue Versionen.

Das Einschalten ist einfach: einen apm-Eintrag in .github/dependabot.yml ergänzen, das Verzeichnis mit apm.yml angeben und einen Update-Zeitplan wählen. Zur Verfügbarkeit: Die APM-Unterstützung ist auf github.com für alle GitHub-Tarife allgemein verfügbar und kommt mit GitHub Enterprise Server 3.24. Selbst gehostete Unternehmen können sie also noch nicht nutzen, der Zeitpunkt hängt vom eigenen Upgrade-Tempo ab.

Das Changelog besteht nur aus wenigen Sätzen, die Einzelheiten stehen im APM-Abschnitt der GitHub-Dokumentation, der strenger ist. Dependabot aktualisiert Einträge unter dependencies.apm und devDependencies.apm, und wie, hängt davon ab, wie eine Abhängigkeit angeheftet ist. Eine an ein SemVer-Tag angeheftete Abhängigkeit wird auf das neueste SemVer-Tag aktualisiert, sowohl bei einfachen Tags als auch bei paketbezogenen Tags, die mit dem Paketnamen beginnen müssen, also dem Repository-Namen oder dem letzten Bestandteil des Pfads eines virtuellen Pakets. Eine an einen Commit-SHA angeheftete Abhängigkeit wird auf den Commit des neuesten annotierten Release-Tags ohne Vorabversion aktualisiert, und der Tag-Name wird als Kommentar ergänzt. Eine an einen Branch angeheftete Abhängigkeit wird auf den neuesten Commit des Branches aktualisiert; dann ändert sich nur apm.lock.yaml, weil das Manifest weiter den Branch nennt, und eine vorhandene apm.lock.yaml ist nötig. Gibt es im Repository eine apm.lock.yaml, erzeugt Dependabot sie mit apm lock neu, legt aber keine an, wenn keine existiert.

Die Dokumentation gibt konkrete Beispiele, mit denen sich die Regeln leichter prüfen lassen. Eine Abhängigkeit der Form octo-org/octo-skills#v1.0.0 wird auf das neueste SemVer-Tag aktualisiert. Ein paketbezogenes Tag sieht aus wie octo-org/octo-skills/skills/review#review-v1.4.0, wobei das Tag mit dem Paketnamen review beginnt. Eine Abhängigkeit der Form octo-org/octo-skills# mit einem 40-stelligen SHA wird auf den Commit des neuesten annotierten Release-Tags verschoben und erhält einen Kommentar wie # v1.4.0. Eine Abhängigkeit octo-org/octo-skills#main wandert auf den neuesten Commit von main. Dagegen stehen octo-org/octo-skills ohne Ref, ./my-package als lokaler Pfad und ein Eintrag mit http://-Klon-URL alle auf der Liste der übersprungenen Fälle. Jede im eigenen Manifest verwendete Schreibweise mit dieser Liste abzugleichen ist verlässlicher, als die wenigen Sätze des Changelogs zu lesen.

Das ist unsere Lesart, nicht die der Dokumentation: Die Art der Anheftung bestimmt, wie gut sich ein Update prüfen lässt. Ein SemVer-Tag erzeugt in apm.yml eine lesbare Änderung, die der Prüfende mit den Release Notes vergleichen kann. Ein Commit-SHA bietet Reproduzierbarkeit, und der von Dependabot ergänzte Tag-Kommentar zeigt dem Prüfenden, zu welchem Release der Commit gehört. Ein Team, das Anweisungen für Agenten automatisch aktualisieren will, bevorzugt deshalb womöglich diese beiden Arten und hebt Branch-Anheftungen für Abhängigkeiten auf, denen es schon voll vertraut, weil der Prüfende daraus kaum ein Signal erhält. Verlangen die Teamregeln für jede Änderung eine nachvollziehbare Versionsnummer, passen annotierte Release-Tags besser.

Die Dokumentation nennt auch, was Dependabot nicht aktualisiert, und genau dort sollte man prüfen. Einträge in Objektform (Maps mit git, registry, id oder path) und mcp-Einträge werden übersprungen. Ebenso Einträge ohne Ref, etwa ein bloßer Repository-Name, lokale Pfade, auf Azure DevOps gehostete Einträge, Einträge mit http://- oder git://-Klon-URL, als YAML-Blockskalare oder als Zeichenketten mit Escape-Sequenzen geschriebene Einträge und abgekürzte Commit-SHAs. Kurzformen werden auch übersprungen, wenn das Manifest registries.default setzt, während Einträge mit ausdrücklicher Klon-URL weiter aktualisiert werden. Private Repositories werden über in dependabot.yml konfigurierte Git-Registries unterstützt.

In der Praxis wird nicht jede APM-Abhängigkeit automatisch verfolgt. Viele Teams schreiben nur den Repository-Namen ohne Ref oder verweisen auf gemeinsame Skill-Pakete per lokalem Pfad; diese werden still übersprungen, ohne dass ein Pull Request erscheint. Nach dem Aktivieren sollte man einmal das Dependabot-Laufprotokoll ansehen, um zu bestätigen, dass die wichtigen Abhängigkeiten erkannt wurden, statt anzunehmen, ein konfigurierter Eintrag bedeute volle Abdeckung.

Ein weiterer Punkt ist unsere Einschätzung, nicht der Inhalt des Changelogs. Fähigkeiten, Prompts und Anweisungen sind Text, nach dem Agenten handeln, ihr Update ändert also das Verhalten der Agenten. Das Changelog äußert sich nicht zu Prüfung oder Vertrauenskontrollen, daher ist es klug, diese Pull Requests wie Codeänderungen von Hand zu prüfen, besonders bei an Branches angehefteten Abhängigkeiten, weil ein Branch-Update nur die Lockdatei ändert und das Manifest keinen Unterschied zeigt.