Die Programmieraufgabe kommt im Bewerbungsprozess. Ein Repository herunterladen, Abhängigkeiten installieren, das Projekt starten: Für Entwickler ist das Routine. Genau diese Routine nutzen nordkoreanischen Akteuren zugeschriebene Angriffe aus. Der ausgeführte Code soll Zugangsdaten vom Rechner stehlen. Gehören dazu Schlüssel für GitHub oder eine Paketverwaltung, kann aus einem kompromittierten Arbeitsplatz ein Zugang zur Software-Lieferkette werden.
Bei der unter dem Namen DeceptiveDevelopment untersuchten Aktivität dienen gefälschte Stellenangebote und präparierte Programmieraufgaben als Köder. Zu den dabei beobachteten Schadprogrammen gehören BeaverTail und InvisibleFerret. Für betroffene Unternehmen ist vor allem eine Frage entscheidend: Welche weiteren Systeme darf der Rechner erreichen, auf dem die Aufgabe ausgeführt wurde?
Der erste Zugriff braucht keine GitHub-Sicherheitslücke
Der Einstieg erfolgt über Social Engineering. Ein vermeintlicher Recruiter oder Auftraggeber liefert einen plausiblen Anlass, fremden Code auszuführen. Ein kleines Testprojekt passt zur Situation und verlangt Handlungen, die im Entwicklungsalltag kaum auffallen. Schon die Installation von Abhängigkeiten kann Skripte ausführen; anschließend laufen möglicherweise weitere Prozesse beim Start der Anwendung.
Vom Coding-Test zum möglichen Lieferkettenangriff
Die Angriffskette führt von einer präparierten Programmieraufgabe über die Ausführung und den Diebstahl von Zugangsdaten zum möglichen Missbrauch von Repositories und Veröffentlichungen. Die letzten Schritte hängen von den erbeuteten Rechten ab.
Dafür ist nicht zwingend eine ungepatchte Schwachstelle nötig. Der Entwickler startet das Projekt selbst, und dessen Code arbeitet zunächst mit den Berechtigungen seines Benutzerkontos. Kann dieses Konto lokale Dateien lesen, sind dort gespeicherte Geheimnisse grundsätzlich erreichbar. Dazu können Zugriffstoken, private SSH-Schlüssel, Konfigurationsdateien und Zugangsdaten aus Browsern gehören. Welche Daten tatsächlich zugänglich sind, hängt von Betriebssystem, Speicherung und zusätzlichen Schutzmechanismen ab.
Die entscheidende Grenze verläuft damit zwischen einem unbekannten Testprojekt und einer bereits angemeldeten Arbeitsumgebung. Ein glaubwürdiges Gespräch über eine Stelle ist keine belastbare Vertrauensprüfung für den mitgelieferten Code.
Gestohlene Rechte bestimmen die Reichweite
Ein erbeuteter Zugang ist nicht automatisch ein Generalschlüssel. Ein Token mit reinem Lesezugriff erlaubt keine Veröffentlichung manipulierter Pakete. Ein SSH-Schlüssel für ein Repository gewährt nicht zwangsläufig Zugriff auf die Paketregistrierung. Und selbst Schreibrechte müssen nicht ausreichen, um geschützte Branches oder vorgeschriebene Freigaben zu umgehen.
Gefährlich wird es dort, wo mehrere Befugnisse auf derselben Maschine zusammenlaufen: Quellcode bearbeiten, Änderungen übertragen, Build-Prozesse verändern und Releases veröffentlichen. Dann kann ein einzelner kompromittierter Arbeitsplatz mehrere Stationen der Entwicklung erreichen. Auch private Repositories sind betroffen, wenn die gestohlenen Zugangsdaten entsprechende Rechte besitzen.
Für GitHub und andere Code-Plattformen kann der erste missbräuchliche Zugriff wie eine reguläre Entwickleraktion aussehen. Deshalb genügt es nicht, ausschließlich nach Malware im Quelltext zu suchen. Ungewöhnliche Anmeldungen, neue Schlüssel, veränderte Workflows und unerwartete Veröffentlichungen gehören ebenfalls zur Untersuchung.
Vom Repository zum ausgelieferten Paket liegen weitere Hürden
Eine manipulierte Datei im Repository erreicht nicht automatisch alle Nutzer eines Projekts. Dafür muss sie die weiteren Schritte bis zur Auslieferung durchlaufen. Reviews, Branch-Schutz, getrennte Veröffentlichungsrechte und kontrollierte Build-Prozesse können diesen Weg unterbrechen. Fehlen solche Grenzen oder sind auch deren Zugangsdaten kompromittiert, wächst die mögliche Reichweite.
Besonders kritisch sind Änderungen an Automatisierung und Paketierung. Sie können beeinflussen, welcher Code während eines Builds ausgeführt wird oder welche Dateien im veröffentlichten Paket landen. Ein unauffälliger Quelltextvergleich allein reicht deshalb nicht immer aus, um ein Release zu beurteilen. Auch Build-Konfiguration, Abhängigkeiten und das tatsächlich ausgelieferte Artefakt müssen betrachtet werden.
Für nachgelagerte Nutzer zählt die konkrete betroffene Version. Die allgemeine Popularität eines Pakets sagt noch nicht, wie viele Systeme schädlichen Code ausgeführt haben. Dafür sind unter anderem Veröffentlichungszeitraum, Installationen, verwendete Versionen und die Ausführungsbedingungen der Schadfunktion relevant.
Testaufgaben gehören in eine getrennte Umgebung
Die wirksamste Vorsorge beginnt vor der Ausführung. Unbekannte Bewerbungsprojekte sollten in einer kurzlebigen, isolierten Umgebung laufen, die keine produktiven Zugangsdaten enthält. Eine separate virtuelle Maschine ohne eingebundene Arbeitsverzeichnisse und ohne weitergereichten SSH-Agenten begrenzt den Zugriff auf die eigentliche Entwicklungsumgebung. Netzwerkzugriffe sollten dabei so weit wie praktikabel eingeschränkt und beobachtbar sein.
Ein Container bietet nicht automatisch dieselbe Trennung. Eingebundene Verzeichnisse, übergebene Umgebungsvariablen oder Zugriff auf den Docker-Socket können die Isolation erheblich schwächen. Entscheidend ist die tatsächliche Konfiguration. Auch ein vermeintlich harmloser Installationsschritt verdient eine Prüfung, bevor er auf dem Arbeitsrechner ausgeführt wird.
Auf Organisationsseite helfen eng begrenzte und möglichst kurzlebige Token, getrennte Konten für Veröffentlichungen sowie verpflichtende Freigaben für sensible Änderungen. Mehrfaktor-Authentifizierung bleibt wichtig. Sie macht bereits gestohlene und weiterhin gültige Zugriffstoken jedoch nicht automatisch unbrauchbar. Wo möglich, sollten Veröffentlichungen über kontrollierte Prozesse mit kurzlebigen Berechtigungen statt über dauerhaft gespeicherte persönliche Geheimnisse erfolgen.
Nach einer Ausführung müssen auch die Zugänge geprüft werden
Hat ein Entwickler ein verdächtiges Projekt bereits gestartet, reicht das Löschen des Projektordners nicht aus. Der Rechner sollte isoliert und nach dem vorgesehenen Incident-Response-Verfahren untersucht werden. Potenziell offengelegte Token und Schlüssel müssen von einem vertrauenswürdigen System aus widerrufen oder ersetzt werden; betroffene Sitzungen sind zu beenden.
Parallel müssen Verantwortliche nachvollziehen, was mit diesen Rechten möglich war und was tatsächlich passiert ist. Dazu gehören Zugriffsprotokolle, Änderungen an Repositories und Build-Workflows, neu eingerichtete Schlüssel sowie Paketveröffentlichungen. Bei Hinweisen auf manipulierte Releases müssen konkrete Versionen identifiziert und nachgelagerte Nutzer informiert werden.
Die operative Konsequenz ist klar: Ein Entwicklerrechner mit Veröffentlichungsrechten ist Teil der Produktionssicherheit. Wer dort fremden Code testet, braucht eine belastbare Trennung zwischen Testumgebung und den Zugängen, denen Kollegen, Build-Systeme und Paketnutzer vertrauen.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
