Was MDM auf Entwicklercomputern nicht schützen kann (und was man dagegen tun kann)

Mobile Device Management (MDM) ist eine Art von Software, die von Unternehmen eingesetzt wird, um die Mobilgeräte ihrer Mitarbeiter zu sichern, zu verwalten und zu überwachen. Tools wie Jamf, Kandji und Microsoft Intune bieten IT-Teams Transparenz und Kontrolle über jede genehmigte Anwendung im gesamten Gerätepark. Bei compliance wie SOC 2 oder ISO 27001 ist MDM oft eine zentrale Komponente, um die Gerätekontrolle nachzuweisen und die Datensicherheit zu gewährleisten. Wenn Ihr MDM bereits im Einsatz ist, herzlichen Glückwunsch: Sie haben die BYOD-Sicherheitsherausforderung von 2012 gemeistert.

Das Problem ist, dass die Angriffsfläche moderner Entwickler mittlerweile still und leise das Maß überschritten hat, für das MDM ursprünglich konzipiert wurde. Wenn Entwicklerrechner kompromittiert werden, ist der Einstiegspunkt selten das Betriebssystem oder eine von der IT-Abteilung bereitgestellte Komponente. Kürzlich ermöglichte eine bösartige VS-Code-Erweiterung, die auf dem Gerät eines Entwicklers installiert war, einem Angreifer den Zugriff auf GitHub, wodurch Tausende interner Repositorys offengelegt wurden. Zuvor hatte der Mini-Shai-Hulud-npm-Wurm über 160 Pakete kompromittiert, darunter Mistral und TanStack, indem er Anmeldedaten von Entwickler-Rechnern stahl. Entwickelnde sind das Hauptziel für Angreifer, und dennoch ist MDM davon nichts mitbekommen. 

In diesem Beitrag geht es darum, wo die Schwachstellen von MDM liegen, was auch EDR übersieht und wie Sie sicherstellen können, dass die Geräte Ihrer Entwickler tatsächlich geschützt sind.

Wie MDM funktioniert und wo seine Grenzen liegen

MDM arbeitet auf Betriebssystem- und Anwendungsebene. In der Praxis bedeutet dies, Betriebssystem-Updates zu installieren, Passwortrichtlinien durchzusetzen, Zertifikate zu verwalten, Festplattenverschlüsselung zu erzwingen, ein Verzeichnis der installierten Anwendungen zu führen und für den Fall von Verlust oder Diebstahl eines Geräts die Möglichkeit zur Fernlöschung bereitzuhalten. Bei Anwendungen, die über Standardmechanismen des Betriebssystems wie den App Store, über Unternehmenssoftware-Bereitstellungen oder über signierte Binärdateien, die über eine Verwaltungskonsole bereitgestellt werden, bereitgestellt werden, funktioniert MDM gut.

Die unten aufgeführten Schwachstellen haben alle dieselbe Ursache. Paketmanager wie npm und pip sind Tools im Benutzerbereich. Sie laden Software aus Registern, zu denen MDM keinerlei Verbindung hat, in Projektverzeichnisse, in die MDM keinen Einblick hat – ausgelöst durch Befehle, die in der Shell eines Entwicklers ausgeführt werden. Dasselbe gilt für IDE-Erweiterungen, die über einen Marktplatz installiert werden, für Browser-Plugins und für KI-Tools. Keines dieser Elemente durchläuft die Installationsmechanismen auf Betriebssystemebene, die von MDM überwacht werden.

Was MDM nicht abdeckt 

Paket-Registerstellen 

MDM weiß zwar, welche Anwendungen die IT-Abteilung genehmigt und bereitgestellt hat, hat jedoch keinen Einblick darin, was ein Entwickler aus einem Paket-Registry abruft. Das ist von Bedeutung, da Pakete bei der Installation über Lebenszyklus-Hooks Code ausführen, bevor Ihre Sicherheitstools überhaupt reagieren können. Bis ein bösartiges Paket seine Payload ausgeführt hat, hat es möglicherweise bereits Anmeldedaten vom Rechner des Entwicklers abgegriffen. Der Mini-Shai-Hulud-Wurm funktionierte genau so: Er stahl unbemerkt npm- und GitHub-Tokens und nutzte diese dann, um bösartige Versionen des nächsten Pakets in der Kette zu veröffentlichen.

KI-Codierungstools haben dem Ganzen eine neue Wendung gegeben. KI-Modelle „erfinden“ Paketnamen, und Angreifer registrieren diese, bevor es jemand bemerkt. Ein Entwickler bittet ein KI-Codierungstool, eine Abhängigkeit hinzuzufügen; das Tool schlägt selbstbewusst ein Paket vor, das gar nicht existiert, und ein Angreifer hat diesen Namen bereits auf npm mit einer bösartigen Payload beansprucht. MDM übersieht die Installation in beiden Fällen. 

Browser-Erweiterungen

Obwohl ein Großteil der Arbeit von Entwicklern im Browser stattfindet, schenken die meisten Sicherheitsteams diesem Aspekt bei weitem nicht genug Beachtung. GitHub, Cloud-Konsolen, CI/CD-Dashboards und interne Tools sind den ganzen Tag über offen und authentifiziert zugänglich. Darüber hinaus gibt es Browser-Erweiterungen, denen die meisten Nutzer ohne zu zögern Berechtigungen erteilen. Eine Erweiterung mit Zugriff auf alle Websites kann alles lesen, was der Browser lädt, einschließlich authentifizierter Sitzungen und aller Daten, die während der Übertragung über die Seite laufen. MDM hat keinerlei Einblick in diese Vorgänge. 

Der Hackerangriff auf Vercel Anfang dieses Jahres hat gezeigt, wie schnell dies zu einem Problem werden kann. 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 durch einen Infostealer kompromittiert wurde, fand der Angreifer das gespeicherte OAuth-Token und nutzte es, um auf die internen Systeme von Vercel zuzugreifen. MDM konnte diese bösartige Erweiterung nicht erkennen, da sie vom Entwickler und nicht von der IT-Abteilung installiert wurde und ihre Aktivitäten mit den gewährten Berechtigungen für MDM völlig unsichtbar waren.

Was die Verwaltung von Browser-Erweiterungen besonders schwierig macht, ist die Tatsache, dass sie im Hintergrund aktualisiert werden. Eine Erweiterung, die bei der Installation unbedenklich war, kann über Nacht ein schädliches Update erhalten, und jeder Nutzer, bei dem die automatische Aktualisierung aktiviert ist, erhält dieses automatisch. Der Cyberhaven-Hack im Jahr 2024 verlief genau nach diesem Muster. Ein Phishing-Angriff auf ein Entwicklerkonto führte dazu, dass ein schädliches Update an alle Nutzer verteilt wurde, das 24 Stunden lang aktiv war, bevor es jemand bemerkte.

IDE-Erweiterungen

Von all der Software, die ein Entwickler installiert, steht ein VS Code-Plugin den Kronjuwelen am nächsten. Es läuft direkt innerhalb der Entwicklungsumgebung und bietet einen besseren Einblick in die Arbeit des Entwicklers als fast alles andere auf dem Rechner. Ähnlich wie Browser-Erweiterungen werden IDE-Erweiterungen von den Entwicklern selbst installiert, aktualisieren sich im Hintergrund und befinden sich außerhalb des Sichtfelds von MDM-Lösungen. Der Unterschied besteht darin, dass IDE-Erweiterungen Zugriff auf Quellcode und Anmeldedaten haben.

Der Hackerangriff auf GitHub hat dies deutlich gemacht. Der Angriffspunkt war die VS-Code-Erweiterung „Nx Console“, eine von GitHub verifizierte Erweiterung mit 2,2 Millionen Installationen, die im Visual Studio Marketplace lediglich 18 Minuten lang kompromittiert war. VS Code sucht jedes Mal nach Erweiterungs-Updates, wenn der Editor eine Galerie-Interaktion durchführt, die Seitenleiste öffnet, eine Marketplace-Suche durchführt oder Metadaten im Hintergrund abruft. Daher gelangte die bösartige Version während dieser 18 Minuten automatisch und ohne Aufforderung oder Warnung zu den Entwicklern, deren Editor geöffnet war. 3.800 interne Repositorys von GitHub wurden offengelegt. MDM war an der Erkennung dieser Vorfälle in keiner Weise beteiligt.

KI-Tools, MCP-Server und Programmieragenten

KI-Programmierwerkzeuge sind mittlerweile fester Bestandteil der Arbeitsabläufe von Entwicklern. Cursor, GitHub Copilot, Claude Code und Windsurf führen Aktionen aus, oft ohne dass ein Mensch überprüft, was installiert wird oder wohin die Daten gelangen. Sicherheitsteams, die sich auf MDM verlassen, tappen in dieser Hinsicht weitgehend im Dunkeln.

MCP-Server gehen noch einen Schritt weiter, indem sie KI-Assistenten die Möglichkeit geben, mit externen Diensten zu interagieren. Und wie jede andere Abhängigkeit können auch sie kompromittiert werden. Im September 2025 wurde das npm-Paket „postmark-mcp“ als erster bestätigter bösartiger MCP-Server in freier Wildbahn identifiziert. Es leitete jede ausgehende E-Mail unbemerkt per Blindkopie an eine vom Angreifer kontrollierte Adresse weiter. Der MCP-Server hatte fünfzehn saubere Versionen, bevor die Hintertür in der sechzehnten Version auftauchte.

Dies ist eine völlig neue Angriffsfläche, die von den meisten Sicherheitsteams noch nicht im Blick hat.

Was ist mit EDR? 

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

Das Problem ist, dass EDR erst nach der Ausführung aktiv wird. Bis es etwas zu erkennen gibt, ist ein bösartiger Post-Install-Hook bereits ausgeführt worden, Zugangsdaten wurden bereits abgegriffen, und im Fall von Mini Shai-Hulud wurden gestohlene Tokens bereits dazu verwendet, die nächste Welle kompromittierter Pakete zu veröffentlichen. EDR erkennt „npm install“ nicht. Es sieht einen Prozess, der wie normale Entwicklungsaktivitäten aussieht. Zu diesem Zeitpunkt ist es bereits zu spät.

So schließen Sie die Lücken

MDM und herkömmliche EDR-Lösungen werden nicht verschwinden – und das sollten sie auch nicht. Das Ziel besteht darin, zusätzliche Kontrollmechanismen darüber zu legen, die die entwicklerspezifische Angriffsfläche abdecken, für die diese Lösungen ursprünglich nicht konzipiert wurden.

Ein Mindestalter für das Paket festlegen

Neue Pakete bergen ein hohes Risiko. Eine Richtlinie mit einer Mindestaltergrenze von 48 Stunden verhindert Typosquatting am selben Tag und schnell verbreitete Malware-Kampagnen, bevor diese Ihre Entwickler erreichen. Sowohl die „Mini Shai-Hulud“-Kampagne als auch der Axios-Angriff verteilten ihre Schadcode über Pakete, die innerhalb weniger Stunden nach der Kompromittierung veröffentlicht wurden. Eine Richtlinie mit einer Mindestaltergrenze von 48 Stunden hätte beide blockiert, bevor sie auch nur einen einzigen Entwicklerrechner erreichten. Es ist anzumerken, dass dies für npm und allgemeine Software-Abhängigkeitspakete gilt. Bei sich automatisch aktualisierenden Erweiterungen hilft dies nicht, was ein anderes Problem darstellt.

Installationsskripte standardmäßig blockieren

Die meisten Teams konfigurieren --Skripte ignorieren in ihrer Pipeline, um zu verhindern, dass Postinstall-Hooks automatisch ausgeführt werden. Nur wenige wenden dieselbe Standardeinstellung auf Entwicklerrechner an. Der Mini-Shai-Hulud-Wurm verbreitete seine Schadcode über einen Postinstall-Hook. Wenn die lokale Umgebung eines Entwicklers Installationsskripte standardmäßig ausführt, liegt dort die Sicherheitslücke. Sie können ignore-scripts=true weltweit .npmrc Datei, aber es ist schwierig, diese ohne entsprechende Tools im gesamten Team konsequent durchzusetzen.

Browser- und IDE-Erweiterungen prüfen

Die meisten Sicherheitsteams haben keine Ahnung, welche VS-Code-Erweiterungen oder Browser-Plugins auf den Rechnern ihrer Entwickler installiert sind. Sie benötigen einen Überblick darüber, was installiert ist, von wem und ob es kürzlich aktualisiert wurde. Die Sicherheitsverletzungen bei GitHub und Vercel begannen beide mit Erweiterungen, die niemand überwachte. Das Ziel ist es, eine Liste zugelassener Erweiterungen zu führen und diese zentral durchzusetzen, doch das lässt sich in großem Maßstab nicht manuell bewerkstelligen.

Überwachen Sie, welche KI-Entwicklungstools installiert werden

Entwickler nutzen Cursor, Claude Code, Copilot und eine ständig wachsende Zahl von MCP-Servern – oft ohne dass die Sicherheitsteams davon wissen. „Shadow AI“ ist eine reale Gefahr. Was man nicht sieht, kann man auch nicht kontrollieren, und KI-Tools, die Pakete selbstständig und ohne menschliche Überprüfung installieren, sind ein aktiver Teil Ihrer Angriffsfläche.

Verwenden Sie spezielle Tools für Entwickler-Endpunkte

Die oben genannten Kontrollmaßnahmen lassen sich entweder nur schwer in großem Maßstab konsequent durchsetzen oder decken nicht die gesamte Angriffsfläche ab. Spezielle Endpunkt-Tools für Entwickler wurden eigens dafür entwickelt, die Installation von Paketen, die Aktivitäten von Erweiterungen und das Verhalten von KI-Tools auf Geräteebene auf jedem einzelnen Rechner der Flotte zu überwachen.

Schutzausrüstung Aikido lässt sich über Ihr bestehendes MDM bereitstellen und umfasst Paketregister, IDE-Erweiterungen, Browser-Plugins sowie Marktplätze für KI-Tools. Wenn ein Entwickler npm i axios Da die neueste Version erst vor einer Stunde veröffentlicht wurde, greift „Device Protection“ auf die aktuellste Version zurück, die die Richtlinie für ein Mindestalter von 48 Stunden erfüllt. Sichere Installationen werden ohne Unterbrechung durchgeführt. Schädliche Installationen werden blockiert, bevor sie den Computer erreichen.

Es basiert auf Aikido , das täglich über 100.000 verdächtige Projekte analysiert. Wenn Sie ohne vollständige Bereitstellung beginnen möchten, ist Safe Chain der Open-Source-Einstieg. Hätten Sie es während der Angriffe von Shai-Hulud, TeamPCP und Axios im Einsatz gehabt, wären Sie geschützt gewesen.

MDM ist notwendig, aber nicht ausreichend

Das soll kein Argument dafür sein, MDM abzuschaffen. Es erfüllt seinen Zweck, und für compliance Gerätevorschriften, die Zertifikatsverwaltung und den Nachweis der Kontrolle gegenüber Ihren Prüfern ist es nach wie vor das richtige Werkzeug. Doch Entwicklerrechner haben sich still und leise zu einer eigenen Kategorie von Endgeräten entwickelt, deren Angriffsfläche es zum Zeitpunkt der Entwicklung von MDM noch gar nicht gab.

Die Frage, die sich die meisten Sicherheitsteams stellen sollten, lautet: Was geschieht zwischen der MDM-Richtlinie und der Installation des Pakets?

​