Was MDM auf Entwickelnden-Maschinen nicht schützen kann (und was dagegen zu tun ist)

Mobile Device Management (MDM) ist eine Softwareart, die von Organisationen verwendet wird, um die mobilen Geräte ihrer Mitarbeitenden zu sichern, zu verwalten und zu überwachen. Tools wie Jamf, Kandji und Microsoft Intune geben IT-Teams Transparenz und Kontrolle über jede genehmigte Anwendung in der gesamten Flotte. Für Compliance-Frameworks wie SOC 2 oder ISO 27001 ist MDM oft eine Kernkomponente, um Gerätekontrolle zu demonstrieren und Datensicherheit zu gewährleisten. Wenn Ihr MDM implementiert ist, herzlichen Glückwunsch, Sie haben die BYOD-Sicherheitsherausforderung von 2012 gelöst.

Das Problem ist, dass die moderne Angriffsfläche für Entwickelnde stillschweigend über das hinausgewachsen ist, wofür MDM konzipiert wurde. Wenn Entwickelnden-Maschinen kompromittiert werden, ist der Einstiegspunkt selten das Betriebssystem oder etwas, das von der IT bereitgestellt wurde. Kürzlich ermöglichte eine bösartige VS Code-Erweiterung, die auf dem Gerät eines Entwickelnden installiert war, einem Angreifer, GitHub zu kompromittieren und Tausende interner Repositories offenzulegen. Davor kompromittierte der Mini Shai-Hulud npm-Wurm über 160 Pakete, darunter Mistral und TanStack, indem er Anmeldeinformationen von Entwickelnden-Maschinen stahl. Entwickelnden-Geräte sind das Hauptziel für Angreifer, und doch ist MDM nicht schlauer. 

Dieser Beitrag behandelt, wo die blinden Flecken von MDM liegen, was EDR ebenfalls übersieht und wie Sie sicherstellen können, dass Ihre Entwickelnden-Geräte tatsächlich geschützt sind.

Wie MDM funktioniert und wo es aufhört

MDM arbeitet auf der OS- und Anwendungsebene. In der Praxis bedeutet das das Pushen von OS-Updates, das Erzwingen von Passwortrichtlinien, das Verwalten von Zertifikaten, das Erzwingen von Festplattenverschlüsselung, das Führen eines Inventars installierter Anwendungen und das Bereithalten einer Remote-Wipe-Option für verlorene oder gestohlene Geräte. Für Anwendungen, die über Standard-OS-Mechanismen wie den App Store, Unternehmenssoftware-Bereitstellungen und signierte Binärdateien, die über eine Verwaltungskonsole gepusht werden, bereitgestellt werden, funktioniert MDM gut.

Die unten genannten blinden Flecken haben alle dieselbe Ursache. Paketmanager wie npm und pip sind User-Space-Tools. Sie ziehen Software aus Registries, zu denen MDM keine Beziehung hat, in Projektverzeichnisse, in die MDM keine Einsicht hat, ausgelöst durch Befehle, die in der Shell eines Entwickelnden ausgeführt werden. Dasselbe gilt für IDE-Erweiterungen, die über einen Marktplatz installiert werden, Browser-Plugins und KI-Tools. Keines davon durchläuft die OS-level Installationsmechanismen, die MDM überwacht.

Was MDM übersieht 

Paket-Registries 

MDM weiß, welche Anwendungen die IT genehmigt und bereitgestellt hat, aber es hat keine Sichtbarkeit darüber, was ein Entwickelnde aus einem Paket-Registry zieht. Das ist wichtig, da Pakete Code zur Installationszeit über Lifecycle-Hooks ausführen, bevor Ihre Sicherheits-Tools überhaupt reagieren können. Wenn ein bösartiges Paket seine Payload ausgeführt hat, hat es möglicherweise bereits Anmeldeinformationen vom Rechner des Entwickelnden abgegriffen. Der Mini Shai-Hulud-Wurm funktionierte genau so: Er entwendete stillschweigend npm- und GitHub-Tokens und nutzte diese dann, um bösartige Versionen des nächsten Pakets in der Kette zu veröffentlichen.

KI-Coding-Tools haben dem Ganzen eine neue Wendung gegeben. KI-Modelle halluzinieren Paketnamen, und Angreifer registrieren diese, bevor es jemand bemerkt. Ein Entwickelnde bittet ein KI-Coding-Tool, eine Abhängigkeit hinzuzufügen, das Tool schlägt selbstbewusst ein nicht existierendes Paket vor, und ein Angreifer hat diesen Namen bereits auf npm mit einer bösartigen Payload beansprucht. MDM übersieht die Installation so oder so. 

Browser-Erweiterungen

Obwohl ein Großteil der Arbeit eines Entwickelnden im Browser stattfindet, machen sich die meisten Sicherheitsteams nicht annähernd genug Sorgen darüber. GitHub, Cloud-Konsolen, CI/CD-Dashboards und interne Tools sind den ganzen Tag über geöffnet und authentifiziert. Browser-Erweiterungen setzen auf dieser Umgebung auf, mit Berechtigungen, die die meisten Menschen ohne langes Nachdenken erteilen. Eine Erweiterung mit Zugriff auf alle Websites kann alles lesen, was der Browser lädt, einschließlich authentifizierter Sitzungen und allem, was während der Übertragung die Seite passiert. MDM hat keinerlei Sichtbarkeit in all dies. 

Die Vercel-Datenpanne Anfang dieses Jahres zeigte, wie schnell dies zu einem Problem wird. Ein Vercel-Mitarbeiter installierte eine Chrome-Erweiterung und gewährte ihr OAuth-Zugriff auf seinen Google Workspace. Als das Gerät eines Context.ai-Mitarbeiters später von einem Infostealer kompromittiert wurde, fand der Angreifer das gespeicherte OAuth-Token und nutzte es, um auf die internen Systeme von Vercel zuzugreifen. MDM hätte diese bösartige Erweiterung nicht kennzeichnen können, da sie vom Entwickelnden und nicht von der IT installiert wurde und das, was sie mit den gewährten Berechtigungen tat, für MDM völlig unsichtbar war.

Was Browser-Erweiterungen besonders schwer zu verwalten macht, ist, dass sie sich stillschweigend aktualisieren. Eine Erweiterung, die bei der Installation sauber war, kann über Nacht ein bösartiges Update erhalten, und jeder Benutzer mit aktivierter Auto-Update-Funktion erhält es automatisch. Die Cyberhaven-Datenpanne im Jahr 2024 folgte genau diesem Muster. Ein Phishing-Angriff auf ein Entwickelnden-Konto führte dazu, dass ein bösartiges Update an alle Benutzer verteilt wurde, das 24 Stunden lang aktiv war, bevor es jemand bemerkte.

IDE-Erweiterungen

Von der gesamten Software, die ein Entwickelnde installiert, sitzt ein VS Code-Plugin den Kronjuwelen am nächsten. Es läuft direkt in der Entwicklungsumgebung und bietet mehr Einblick in das, was ein Entwickelnde tut, als fast alles andere auf dem Rechner. Wie Browser-Erweiterungen werden IDE-Erweiterungen von den Entwickelnden selbst installiert, aktualisieren sich stillschweigend und sind nirgendwo im Sichtfeld von MDM. Der Unterschied ist, dass IDE-Erweiterungen Quellcode und Anmeldeinformationen sehen können.

Die GitHub-Datenpanne machte dies deutlich. Der Einstiegspunkt war die Nx Console VS Code-Erweiterung, eine von einem verifizierten Herausgeber stammende Erweiterung mit 2,2 Millionen Installationen, die auf dem Visual Studio Marketplace für nur 18 Minuten kompromittiert wurde. VS Code prüft bei jeder Galerie-Interaktion, dem Öffnen der Seitenleiste, der Marktplatzsuche oder dem Abrufen von Hintergrund-Metadaten auf Erweiterungs-Updates, sodass die bösartige Version Entwickelnde, die den Editor während dieser 18 Minuten geöffnet hatten, automatisch erreichte, ohne Aufforderung und ohne Warnung. 3.800 der internen GitHub-Repositories wurden offengelegt. MDM hatte keinerlei Anteil an der Erkennung davon.

KI-Tools, MCP-Server und Coding-Agents

KI-Coding-Tools sind heute ein Standardbestandteil der Arbeitsweise von Entwickelnden. Cursor, GitHub Copilot, Claude Code und Windsurf führen Aktionen aus, oft ohne dass ein Mensch überprüft, was installiert wird oder wohin Daten gehen. Sicherheitsteams, die sich auf MDM verlassen, agieren dabei weitgehend im Blindflug.

MCP-Server erweitern dies, indem sie KI-Assistenten die Möglichkeit geben, mit externen Diensten zu interagieren. Und wie jede Abhängigkeit können sie kompromittiert werden. Im September 2025 wurde das npm-Paket postmark-mcp zum ersten bestätigten bösartigen MCP-Server in freier Wildbahn. Es kopierte stillschweigend jede ausgehende E-Mail an eine vom Angreifer kontrollierte Adresse. Der MCP-Server hatte fünfzehn saubere Versionen, bevor die Backdoor in der sechzehnten erschien.

Dies ist eine brandneue Angriffsfläche, und die meisten Sicherheitsteams verfolgen sie noch nicht.

Was ist mit EDR? 

Wenn Sicherheitsteams erkennen, dass MDM nicht ausreicht, greifen sie in der Regel als Nächstes zu Endpoint Detection and Response (EDR). Tools wie CrowdStrike und SentinelOne überwachen anomales Prozessverhalten, verdächtige Dateisystemänderungen und Command-and-Control-Callbacks. Wenn Malware aktiv auf einem Rechner läuft, hat EDR eine gute Chance, sie zu erkennen.

Das Problem ist, dass EDR nach der Ausführung agiert. Bis es etwas zu erkennen hat, ist ein bösartiger Postinstall-Hook bereits ausgeführt worden, Anmeldeinformationen wurden bereits abgegriffen, und im Fall von Mini Shai-Hulud wurden gestohlene Tokens bereits verwendet, um die nächste Welle kompromittierter Pakete zu veröffentlichen. EDR sieht keine npm-Installation. Es sieht einen Prozess, der wie normale Entwicklungsaktivität aussieht. Dann ist es zu spät.

Wie man die Lücken schließt

MDM und traditionelles EDR werden nicht verschwinden, und das sollten sie auch nicht. Das Ziel ist es, Kontrollen darüber zu legen, die die entwickelndenspezifische Angriffsfläche abdecken, für die sie nie konzipiert wurden.

Ein Mindestalter für Pakete durchsetzen

Neue Pakete sind mit hohem Risiko verbunden. Eine Mindestalter-Richtlinie von 48 Stunden blockiert Typosquatting am selben Tag und schnelllebige Malware-Kampagnen, bevor sie Ihre Entwickelnden erreichen. Die Mini Shai-Hulud-Kampagne und der Axios-Angriff lieferten ihre Payloads beide über Pakete, die innerhalb weniger Stunden nach der Kompromittierung veröffentlicht wurden. Eine 48-Stunden-Mindestalter-Richtlinie hätte beide blockiert, bevor sie einen einzigen Entwickelnden-Rechner erreicht hätten. Es ist wichtig zu beachten, dass dies für npm und allgemeine Software-Abhängigkeitspakete gilt. Es hilft nicht bei sich automatisch aktualisierenden Erweiterungen, was ein anderes Problem ist.

Postinstall-Skripte standardmäßig blockieren

Die meisten Teams konfigurieren --ignore-scripts in ihrer Pipeline, um die automatische Ausführung von Postinstall-Hooks zu blockieren. Weniger Entwickelnde wenden dieselbe Standardeinstellung auf ihre Maschinen an. Der Mini Shai-Hulud-Wurm lieferte seine Payload über einen Postinstall-Hook aus. Wenn die lokale Umgebung eines Entwickelnden standardmäßig Installationsskripte ausführt, entsteht dort die Angriffsfläche. Man kann dies einstellen ignore-scripts=true in einer globalen .npmrc Datei, aber die konsistente Durchsetzung im gesamten Team ohne entsprechende Tools ist schwierig.

Browser- und IDE-Erweiterungen prüfen

Die meisten Sicherheitsteams haben keine Ahnung, welche VS Code-Erweiterungen oder Browser-Plugins auf den Maschinen ihrer Entwickelnden installiert sind. Sie benötigen Transparenz darüber, was von wem installiert wurde und ob es kürzlich aktualisiert wurde. Die GitHub- und Vercel-Angriffe begannen beide mit Erweiterungen, die niemand überwachte. Eine genehmigte Liste zu pflegen und zentral durchzusetzen, ist das Ziel, aber es ist nichts, was man manuell in großem Umfang tun kann.

Überwachen Sie, was KI-Coding-Tools installieren

Entwickelnde nutzen Cursor, Claude Code, Copilot und eine wachsende Liste von MCP-Servern, oft ohne Wissen der Sicherheitsteams. Shadow AI ist real. Man kann nicht steuern, was man nicht sieht, und KI-Tools, die Pakete autonom ohne menschliche Überprüfung installieren, sind ein aktiver Teil Ihrer Angriffsfläche.

Spezielle Developer Endpoint Tools verwenden

Die oben genannten Kontrollen sind entweder schwer konsistent in großem Umfang durchzusetzen oder sie decken nicht die gesamte Angriffsfläche ab. Spezielle Developer Endpoint Tools sind speziell für die Überwachung von Paketinstallationen, Erweiterungsaktivitäten und dem Verhalten von KI-Tools auf Geräteebene über jede Maschine im gesamten Bestand hinweg konzipiert.

Aikido Device Protection wird über Ihr bestehendes MDM bereitgestellt und deckt Paket-Registries, IDE-Erweiterungen, Browser-Plugins und KI-Tool-Marktplätze ab. Wenn ein Entwickler ausführt npm i axios und die neueste Version vor einer Stunde veröffentlicht wurde, greift Device Protection auf die aktuellste Version zurück, die eine Mindestalter-Richtlinie von 48 Stunden erfüllt. Sichere Installationen werden ohne Unterbrechung durchgeführt. Bösartige werden blockiert, bevor sie die Maschine erreichen.

Es basiert auf Aikido Intel, das täglich über 100.000 verdächtige Projekte analysiert. Wenn Sie ohne vollständige Bereitstellung starten möchten, ist Safe Chain der Open-Source-Einstiegspunkt. Wenn Sie es während der Shai-Hulud-, TeamPCP- und Axios-Angriffe eingesetzt hätten, wären Sie geschützt gewesen.

MDM ist notwendig, aber nicht ausreichend

Dies ist kein Argument für den Ersatz von MDM. Es erfüllt seinen Zweck, und für Device Compliance, Zertifikatsmanagement und die Demonstration von Kontrolle gegenüber Ihren Auditoren ist es immer noch das richtige Tool. Aber die Maschinen von Entwickelnden sind stillschweigend zu einer anderen Kategorie von Endpunkten geworden, mit einer Angriffsfläche, die bei der Entwicklung von MDM noch nicht existierte.

Die Frage, die sich die meisten Sicherheitsteams stellen sollten, ist, was zwischen der MDM-Richtlinie und der Paketinstallation passiert.

​