Wo die GitHub Copilot Erweiterungspunkte die Governance brechen

Viele der jüngsten Erweiterungen des GitHub Copilot-Ökosystems bieten einen echten Mehrwert für einzelne Entwickler, vergrößern aber auch die Sicherheitsfläche, über die ein Unternehmen nachdenken muss. Die meisten dieser neuen Einstiegspunkte ermöglichen es einem Entwickler, ausführbare Anweisungen, Konfigurationen oder vollständige Prozesse aus einem beliebigen Repository im Internet zu ziehen, und zwar mit sehr wenig oder gar keiner zentralen Kontrolle. Dieser Beitrag befasst sich mit den fünf Stellen, an denen die Kluft zwischen "nützlich für einen einzelnen Ingenieur" und "sicher für ein Unternehmen mit 5.000 Mitarbeitern" meiner Meinung nach derzeit am größten ist.

Wir werden uns diese Topis ansehen:

GitHub Copilot CLI-Plugin-Marktplatz

Mit der Copilot CLI können Sie einen Marktplatz für Plugins registrieren und Plugins daraus installieren. Die Startrampe ist ein einziger Befehl:

copilot plugin marketplace add OWNER/REPO
copilot plugin install some-plugin@some-marketplace

Ein Marktplatz ist lediglich ein GitHub-Repository mit einer marketplace.json Datei in .github/plugin/. Es gibt keine Überprüfung, keine Signierung, keinen zentralen Index. Zwei Marktplätze (copilot-plugins und awesome-copilot) sind standardmäßig registriert, aber jeder Benutzer kann jedes andere Repository hinzufügen, einschließlich eines persönlichen Forks oder eines neu erstellten Kontos, das einen echten Plugin-Namen mit einer kleinen Änderung kopiert.

Die Versionierung ist die nächste Lücke. Die CLI-Plugin-Referenz hat ein version Feld in plugin.json, aber der Befehl copilot plugin install hat keine Syntax, um eine Version zu bestimmen. Sie installieren OWNER/REPO, OWNER/REPO:PATH, eine Git-URL, einen lokalen Pfad oder plugin@marketplace und erhalten den HEAD der Quelle, der in diesem Moment gerade aktuell ist. copilot plugin update NAME zieht die neueste Version. Es gibt keine Sperrdatei, kein SHA-Pinning, wie es gh skill hat, und keinen Herkunftsnachweis. Ein Marktplatz kann den Inhalt eines Plugins ändern, ohne das Feld version zu ändern, und die nächste update gibt diese Änderungen an alle Entwickler weiter, die sie installiert haben.

Sie befinden sich in dem Verzeichnis, auf das der Marktplatz verweist, werden auf den Rechner des Benutzers gezogen und im Shell-Kontext des Benutzers mit den Berechtigungen ausgeführt, die der Entwickler hat. Das ist derselbe Kontext wie seine Git-Zugangsdaten, seine Cloud CLI-Sitzungen und alle lokalen Geheimnisse in seiner Umgebung.

Was einem Unternehmen noch fehlt:

Wenn Sie dies damit vergleichen, wie npm oder PyPI normalerweise in einer regulierten Organisation gehandhabt werden (ein privater Proxy, eine Zulassen-Liste, ein Schwachstellen-Scanner in der Pipeline), dann ist die Copilot CLI-Plugin-Geschichte heute ungefähr da, wo npm um 2014 herum war.

GitHub Copilot CLI lokale Erweiterungen

Neben dem Plugin-Marktplatz gibt es eine zweite, fast vollständig undokumentierte Erweiterungsoberfläche, die in die Copilot CLI integriert ist: das Verzeichnis .github/extensions/. Ein detailliertes Reverse-Engineering von htek.dev hat dieses Verzeichnis aus den Copilot SDK-Quellen extrahiert, da es im Wesentlichen keine öffentliche Dokumentation dafür gibt. Die Architektur besteht darin, dass das CLI jedes Unterverzeichnis mit einer extension.mjs Datei findet, es als untergeordneten Node.js-Prozess forkt und mit ihm über JSON-RPC via stdio kommuniziert. Die Erweiterung ruft joinSession() auf und erhält ein Live-Session-Objekt zurück, mit dem sie benutzerdefinierte Tools registrieren, alle Ereignisse im Lebenszyklus des Agenten abfangen, Eingabeaufforderungen umschreiben und Entscheidungen über Berechtigungen treffen kann.

ie Haken im Lebenszyklus sind der Teil, der aus Sicht der Governance wichtig ist:

Der onPermissionRequest Handler im Aufruf joinSession() ersetzt die standardmäßige Eingabeaufforderung des Benutzers bei jeder Tool-Ausführung. Das SDK enthält einen approveAll -Import, der genau das tut, wonach er klingt: Übergeben Sie ihn und die Erweiterung genehmigt stillschweigend jeden Shell-Befehl, jeden Dateischreibvorgang und jeden Netzwerkaufruf, ohne dem Benutzer eine Eingabeaufforderung anzuzeigen.

Die Entdeckungspfade sind es, die dies zu einem flottenweiten Problem machen:

Projekterweiterungen beschatten Benutzererweiterungen bei Namenskollisionen, und die Reihenfolge des Ladens von Erweiterungen ist nicht garantiert. In Kombination mit einem bekannten Fehler, bei dem mehrere Erweiterungen Haken registrieren, führt dies dazu, dass nur die Haken der zuletzt geladenen Erweiterung tatsächlich ausgelöst werden, was zu einem stillen Verhalten führt, das selbst lokal schwer zu überprüfen ist.

Was einem Unternehmen noch fehlt:

Die Funktion ist legitimerweise nützlich: Teams können Architekturregeln durchsetzen, destruktive Befehle blockieren, Linters nach Änderungen ausführen und selbstheilende Testschleifen erstellen. Aber dieselben Fähigkeiten - das Umschreiben von Prompts, die Unterdrückung von Berechtigungen, die Änderung von Tool-Argumenten - sind genau das, was ein Angriff auf die Versorgungskette anstreben würde, und im Moment gibt es überhaupt keine Steuerungsoberfläche auf Orgebene.

Agent Package Manager (APM)

Microsoft APM ist ein Abhängigkeitsmanager für den KI-Agenten-Kontext. Sie deklarieren ein apm.yml, führen apm install aus und es zieht Anweisungen, Skills, Prompts, Agenten, Hooks, Plugins und MCP-Server von jedem Git-Host (GitHub, GitLab, Bitbucket, Azure DevOps, GitHub Enterprise) in jeden erkannten Agenten-Client auf dem Rechner.

Das Manifest befindet sich im Repo selbst (apm.yml und apm.lock.yaml werden zusammen mit dem Code übertragen, genau wie package.json und package-lock.json). Es sieht wie folgt aus:

dependencies:
  apm:
    - anthropics/skills/skills/frontend-design
    - github/awesome-copilot/plugins/context-engineering
    - microsoft/apm-sample-package#v1.0.0
  mcp:
    - name: io.github.github/github-mcp-server
      transport: http

APM liefert eine Governance-Story aus, und sie ist die am besten durchdachte in diesem Beitrag. Es gibt apm-policy.yml mit straffer Vererbung vom Unternehmen über die Organisation bis zum Projektarchiv, einen veröffentlichten Umgehungsvertrag, versteckte Unicode-Scans bei jeder Installation, Hashes für die Integrität von Sperrdateien und einen apm audit --ci Modus, den Sie mit dem Zweigschutz verbinden können.

Der Haken an der Sache ist, dass die gesamte Verwaltung auf freiwilliger Basis erfolgt und außerhalb von GitHub selbst stattfindet. Eine Neuinstallation von apm auf einem Entwickler-Laptop hat keine Policy-Datei. Auch die Richtlinien sind nur für den Pull-Betrieb gedacht: Die kanonische Org-Richtlinie befindet sich auf <org>/.github/apm-policy.yml und die CLI holt sie bei Bedarf ab, wenn ein Entwickler oder ein CI-Job apm install oder apm audit --ci ausführt. Es gibt keinen Push, keinen Agenten und keine zentrale Registrierung. Die abgeholte Richtlinie wird standardmäßig eine Stunde lang lokal in apm_modules/.policy-cache/ zwischengespeichert, und ein fetch_failure: warn|block Knopf entscheidet, was passiert, wenn das org Repo nicht erreichbar ist. Die Voreinstellung ist warn, was bedeutet, dass ein Offline-Laptop mit einem leeren Cache überhaupt keine Richtlinie auflöst. Repo-lokale apm-policy.yml Dateien können extends: org und verschärfen die übergeordneten Regeln nur, lockern sie aber nicht. Die vollständige Mechanik finden Sie in der Richtlinienreferenz und im Governance Guide.

Bis Ihr Sicherheitsteam ein solches Programm schreibt, veröffentlicht und auf allen Rechnern einsetzt, wird apm install problemlos transitive Abhängigkeiten von jedem erreichbaren Git-Host aus auflösen. Und keine Sorge: Ihre CI/CD-Pipeline wird das Gleiche tun (wenn das Tool bereits installiert ist)!

Es gibt auch keine Auto-Installation. APM ist eine reine CLI; es hat keine Editor-Erweiterung, die apm install ausführt, wenn Sie ein Repo in VS Code öffnen. In den Dokumenten wird es ausdrücklich als "wie npm install nach dem Klonen eines Node-Projekts" bezeichnet, was bedeutet, dass der Installationsschritt vom Entwickler ausgeführt werden muss (oder von einem Devcontainer postCreateCommand oder einem CI-Job). Die Kehrseite ist, dass die bereitgestellten Dateien (unter .github/, .claude/, .cursor/, .gemini/) zur Übergabe empfohlen werden, so dass ein Teammitglied, das das Projektarchiv klont, den Agentenkontext sofort erhält, bevor er apm install überhaupt ausführt. Das ist praktisch und bedeutet auch, dass der Agent die von APM bereitgestellten Inhalte in dem Moment liest, in dem der Redakteur das Projektarchiv öffnet, unabhängig davon, ob das lokale CLI jemals aufgerufen wurde.

APM-Pakete können scripts deklarieren (z.B. npm-Skripte), und der Richtlinienverweis legt manifest.scripts: allow|deny genau wegen dieses Risikos offen. Die Voreinstellung ist allow. Ein Angreifer, der ein Paket in Ihren Abhängigkeitsbaum einschleust, kann also auch Skripte einschleusen, es sei denn, Ihre Org-Policy verweigert dies rundheraus.

Die Versionierung ist auf der Manifest-Seite in Ordnung: Abhängigkeiten werden mit #tag oder #shakönnen die Lockfile-Datensätze aufgelöste Commit-SHAs und Content-Hashes aufzeichnen, und die Org-Policy kann require spezifische Versionen mit einem require_resolution von project-wins, policy-wins, oder block. Aktualisierungen erfolgen auf apm install --update, nicht implizit. Direkte und transitive Auflösung bleiben die Teile, um die ich mir Sorgen machen würde: ein Paket, dem Sie vor sechs Monaten vertraut haben, kann in der nächsten Version eine neue Abhängigkeit einbringen, und wenn Ihre Org-Policy nicht ein strenges dependencies.allow Muster hat, schlüpft die neue Quelle durch.

Die MCP-Integration ist einen eigenen Absatz wert. apm install --mcp NAME fügt einen Eintrag unter dependencies.mcp in apm.yml hinzu und schreibt die aufgelöste Serverkonfiguration direkt in die native Konfigurationsdatei jedes erkannten Clients (Copilot, Claude, Cursor, Codex, OpenCode, Gemini) auf dem Dateisystem, wobei die eigene Registrierung oder Richtlinienschicht jedes Clients umgangen wird. Der vollständige Mechanismus ist in der Anleitung zu APM MCP Servern dokumentiert. Praktisch für einen Entwickler, aber auch ein sauberer Weg, um die vorhandenen Richtlinien pro Client zu umgehen. Sie sind dann darauf angewiesen, dass die Laufzeitseite dieser Clients die Richtlinien anwendet, und nur wenige von ihnen tun dies mit Umgehungslösungen.

gh skill jetzt in der GitHub CLI

Hinweis: Dies ist die GitHub CLI, nicht die GitHub Copilot CLI!

Mit dem Befehl gh skill können Sie Agent Skills aus einem beliebigen GitHub-Repository entdecken, installieren, verwalten und veröffentlichen:

gh skill install github/awesome-copilot documentation-writer
gh skill install some-user/some-repo some-skill --pin v1.0.0

Die Supply-Chain-Funktionen sind hier besser. Skills können an ein Tag (unsicher) oder einen Commit-SHA angeheftet werden, die Installation zeichnet den SHA des Git-Baums im Frontmatter des Skills auf, gh skill update vergleicht lokale SHAs mit den entfernten, und gh skill publish bietet an, unveränderliche Releases zu aktivieren, so dass selbst ein Repo-Administrator eine veröffentlichte Version nicht umschreiben kann.

Das Audit-Tooling ist dünn. Die gh skill Handbuch Listen install, preview, publish, search, und update als die einzigen Unterbefehle. Es gibt ein gh skill preview, um den Inhalt einer Fertigkeit vor der Installation zu überprüfen, und gh skill update verwendet den gespeicherten Baum SHA, um Drift zu erkennen, aber es gibt kein gh skill audit und kein org-seitiges Audit-Protokoll darüber, was Ihre Entwickler installiert haben. Wenn Sie wissen möchten, welche Skills auf dem Laptop eines Entwicklers gelandet sind, müssen Sie die Host-Verzeichnisse der Agenten selbst durchsuchen.

Was fehlt, ist eine Erlaubnisliste auf Orgebene. GitHub selbst ist in dieser Hinsicht im Changelog ungewöhnlich direkt:

Die Installation von Skills liegt in Ihrem eigenen Ermessen. Sie werden von GitHub nicht überprüft und können Prompt Injections, versteckte Anweisungen oder bösartige Skripte enthalten. Wir empfehlen dringend, den Inhalt von Skills vor der Installation zu überprüfen.

Das Tooling für eine einzelne Fertigkeit ist also solide, das Tooling für die Frage "Welche Fertigkeiten darf meine Organisation verwenden" jedoch nicht. Ein Entwickler kann gh skill install aus einem beliebigen öffentlichen Repo herunterladen, und der Agent-Host (Copilot, Claude Code, Cursor, Codex, Gemini, alle CLI-Optionen) wird die Fertigkeit beim nächsten Scannen des Verzeichnisses auswählen. Skills sind ein erstklassiger Erweiterungspunkt für das Verhalten des Agenten, was bedeutet, dass ein bösartiger Skill eher einer benutzerdefinierten System-Eingabeaufforderung als einer passiven Konfigurationsdatei entspricht.

Auch hier hilft Dependabot nicht: Agentenfähigkeiten, MCP-Server, APM-Pakete und Copilot CLI-Plugins stehen nicht auf der Liste der von Dependabot unterstützten Ökosysteme. Das bedeutet, dass es keine automatischen Update-PRs, keine Sicherheitshinweise und keine planmäßige Drift-Erkennung für diese Oberflächen gibt. Das müssen Sie selbst entwickeln.

MCP-Server in allen Redaktionen

Dies ist der Bereich, in dem die Situation eher verwirrender als weniger verwirrend geworden ist, auch wenn wirklich daran gearbeitet wurde. Damals, im März 2025, explodierte MCP in die KI-Welt: Erweiterbarkeit von überall zu allem! Seitdem hat sich herausgestellt, dass eine Menge Server und OSS-Repos mit den Dingen herumspielen. Das Schlimme daran ist, dass ein großer Teil dieser Repos inzwischen aufgegeben worden ist. Endor Labs hat dies in seinem Bericht State of Dependency Management 2025 (Zusammenfassung auf der Endor Labs-Pressemitteilung) festgehalten: mehr als 10.000 MCP-Server wurden in weniger als einem Jahr erstellt, 75% davon von einzelnen Entwicklern und nicht von Organisationen, etwa 40% haben überhaupt keine Lizenz und 82% berühren sensible APIs. Die Wartungssignale für den Long Tail sind schwach. Das bedeutet, dass dieselben Server, die Ihre Entwickler im letzten Jahr fröhlich installiert haben, möglicherweise bereits verwaist sind.

Eine kurze Zusammenfassung, wo sich die MCP-Serverkonfiguration heute befindet:

GitHub hat eine private MCP-Registrierungsrichtlinie für Copilot bereitgestellt, mit der ein Unternehmen einschränken kann, mit welchen MCP-Servern sich Copilot-Benutzer verbinden können. Nützlich und ein echter Schritt nach vorn, aber zum Zeitpunkt der Erstellung dieses Artikels gilt sie nur innerhalb von Copilot in VS Code. Die gleiche Copilot-Identität, die in JetBrains, Neovim, der CLI, Spark, Spaces, dem Cloud Agent oder dem Review Agent verwendet wird, fällt nicht unter diese Richtlinie.

Zwei Muster machen es einfacher, die Richtlinie zu umgehen, als es aussieht:

Noch schlimmer: Klonen Sie das Erweiterungs-Repository von github.com, bauen Sie es und verwenden Sie einfach die kompilierte VSIX-Datei in VS Code!

Der praktische Stand ist also: Sie können ein sinnvolles Stück Governance für Copilot in VS Code erhalten, wenn Sie die Registrierung einrichten, und fast keine Governance für einen der anderen Clients auf demselben Laptop, die alle auf dieselben internen Systeme zugreifen können. Wir sind also noch nicht am Ziel, aber zumindest ein Schritt in die richtige Richtung.

VS Code Erweiterungen und die Aufteilung der Registrierung

Die Erweiterungsgeschichte ist die älteste der fünf, und es ist diejenige, die sich in letzter Zeit durch die Cursor- und Windsurf-Style-Forks am meisten verändert hat. Ein paar Dinge sollten Sie unbedingt beachten:

Für eine Org bedeutet dies, dass sich das Bedrohungsmodell von Editor zu Editor unterscheidet, selbst wenn der Entwickler denkt, er installiere "dieselbe Erweiterung". Ein Name auf dem Microsoft Marketplace gehört nicht unbedingt demselben Herausgeber auf Open VSX. Typosquats und Kopien beliebter Erweiterungen tauchen regelmäßig in beiden Registern auf, und eine Erweiterung ist im Grunde genommen beliebiger Code in Ihrem Editor-Prozess mit Zugriff auf Ihre Workspace-Dateien, Ihre Umgebung und alle Token, die der Editor enthält.

Der MCP-Aspekt spielt hier wieder eine Rolle: Eine Erweiterung kann MCP-Server, Einstellungen und Sprachmodellanbieter einbringen. Eine Erweiterung, die Ihre Installationsrichtlinien umgeht, kann also all die Dinge wieder einführen, die Sie auf der Registrierungsebene zu verhindern versucht haben.

Was in der Praxis hilft:

Der Endpunktschutz ist die Schicht, die das auffängt, was die Registrierungen übersehen. Sogar in der offiziellen VS Code-Dokumentation zur Laufzeitsicherheit von Erweiterungen wird direkt darauf hingewiesen, dass eine Erweiterung mit den vollen Rechten des Benutzers ausgeführt wird: Sie kann jede Datei lesen und schreiben, die der Editor lesen kann, Prozesse starten und Netzwerkverbindungen herstellen. Der Marketplace scannt zwar Pakete und überprüft Signaturen (siehe den Microsoft-Beitrag über Sicherheit und Vertrauen im Visual Studio Marketplace), aber es kommt immer wieder zu Vorfällen mit bösartigen Erweiterungen und dem Diebstahl von Anmeldeinformationen (siehe den Wiz-Beitrag über das Supply-Chain-Risiko in VS Code-Erweiterungsmarktplätzen und den Bericht von Check Point über 45.000+ Downloads von bösartigen Erweiterungen). Für eine Organisation bedeutet dies, dass die Kontrollen unterhalb des Editors angesiedelt sein müssen: verwaltete Geräterichtlinien, die unsignierte Binärdateien blockieren, EDR, das den Prozessbaum des Editors auf die gleiche Weise überwacht wie einen Browser, ausgehende DNS- und TLS-Prüfung, die ungewöhnliche Aufrufmuster einer Erweiterung erkennen kann, und ein Lebenszyklus der Workstation, der davon ausgeht, dass ein kompromittierter Editor einer der realistischen Vorfälle ist, auf die Sie reagieren. Scanner von Drittanbietern wie ExtensionTotal können Ihnen eine Risikobewertung für jede Erweiterung geben, bevor Sie sie zulassen, aber behandeln Sie sie als Ergänzung zu Ihrem Endpunkt-Stack und nicht als Ersatz.

Neu: VS Code Unternehmensrichtlinie aktualisiert

VS Code hat Ende April 2026 eine beachtliche Anzahl neuer Unternehmensrichtlinien veröffentlicht (dokumentiert unter code.visualstudio.com/docs/enterprise/policies), die einige der oben beschriebenen Lücken schließen. Die wichtigsten Ergänzungen:

MCP-Serverkontrolle - ChatMCP (chat.mcp.access) ermöglicht es einem Administrator, den Zugriff auf alle installierten MCP-Server über die Geräterichtlinie zu deaktivieren. Dies ist eine einfachere, aber zuverlässigere Kontrolle als die private Copilot-Registrierung allein, da sie unabhängig davon gilt, wie der Server registriert wurde.

Netzwerkfilterung für Agententools - ChatAgentNetworkFilter, ChatAgentAllowedNetworkDomains und ChatAgentDeniedNetworkDomains ermöglichen es Ihnen, die Hosts einzuschränken, die das Fetch-Tool und der integrierte Browser eines Agenten erreichen können. In Kombination mit ChatAgentSandboxEnabled, das Terminal-Befehle in einer Sandbox-Umgebung ausführt, können Sie so den Aktionsradius eines kompromittierten oder bösartigen Tools einschränken.

Genehmigung von Agententools - ChatToolsAutoApprove ermöglicht es Ihnen, den "YOLO-Modus" (chat.tools.global.autoApprove) auf Organisationsebene zu sperren, so dass einzelne Entwickler ihn nicht aktivieren können, und ChatToolsEligibleForAutoApproval ermöglicht es Ihnen, für bestimmte Tools immer eine manuelle Bestätigung zu verlangen.

Kontogesteuerter KI-Zugriff - ChatApprovedAccountOrganizations sperrt alle KI-Funktionen, bis sich der Benutzer bei einem GitHub-Konto anmeldet, das zu einer genehmigten Organisation gehört. Nützlich für Auftragnehmer, BYOD und geteilte Umgebungen, in denen Sie den Copilot-Sitz an eine von Ihrer Organisation kontrollierte Identität binden müssen, bevor etwas läuft.

Unterstützung für Linux-Richtlinien - VS Code 1.106 fügte eine /etc/vscode/policy.json Datei für Linux-Geräte hinzu. Das bedeutet, dass dieselben Richtlinien, die Sie unter Windows und macOS über ADMX oder .mobileconfig bereitstellen, jetzt auch für Linux-Entwickler-Workstations über Ihre bestehenden Konfigurationsmanagement-Tools (Ansible, Puppet, Chef, Salt) gelten.

Richtliniendiagnose - Ein neuer Befehl Developer: Policy Diagnostics erzeugt einen Markdown-Bericht darüber, welche Richtlinien aktiv sind, welche Werte gelten und ob das Account Policy Gate erfüllt oder blockiert ist. Nützlich, wenn Sie einem Prüfer - oder einem verwirrten Entwickler - beweisen müssen, was genau der Rechner durchsetzt.

Diese Ergänzungen verstärken die VS-Code-Zeile in der nachstehenden Übersichtstabelle erheblich. Die Lücken auf den Ebenen Copilot CLI, gh skill und der editorenübergreifenden MCP bleiben offen.

Stand der Plugin-Verwaltung für GitHub Copilot

Wenn ich die verschiedenen Oberflächen danach ausrichte, wie viel Governance auf Orgebene heute tatsächlich möglich ist:

‌

Das Muster bei allen ist, dass die Erfahrung pro Entwickler großartig ist, die Durchsetzung pro Organisation aber entweder nicht vorhanden ist oder aus Richtlinien zusammengestellt werden muss, die sich an anderen Orten befinden als die Funktion selbst. Keines dieser Probleme ist unlösbar, und insbesondere APM zeigt, wie die richtige Form aussieht, aber die Kluft zwischen "ausgeliefert" und "sicher im großen Maßstab einsetzbar" ist größer, als die Changelog-Einträge vermuten lassen.

Wenn Sie in einer größeren Organisation dafür verantwortlich sind, hier die Kurzfassung dessen, was ich tun würde:

Die Funktionen selbst sind in Ordnung. Die fehlende Ebene ist diejenige, die jedes Paket-Ökosystem irgendwann entwickeln musste: ein Ort, an dem eine Organisation angeben kann, welchen Quellen sie vertraut, und der einheitlich für jeden Client gilt, der von diesen Quellen abrufen kann.

Dieser Beitrag erschien ursprünglich auf https://devopsjournal.io/