Entwicklung & Code
Bis auf Weiteres: Eine Geschichte über Daten, die niemand gelöscht hat
Der Ausdruck liegt zwischen uns auf dem Tisch, eine Zeile ist rot markiert:
Weiterlesen nach der Anzeige
31.400 Euro, freigegeben von N. Prenzel, 27. März, 14:52 Uhr.
Das N steht für Nina. Das ist meine Zeile, und jede Zahl darin stimmt.
Mertens fragt, ob ich dazu berechtigt war. Ich sage ja. Er fragt, ob ich das nachweisen kann.
13. März, sechs Monate vorher
Ballmann fällt aus. Er sagt nicht, was er hat, und ich frage auch nicht nach. Am Telefon klingt er wie jemand, der gerade etwas Schlimmes erfahren hat und dem noch nicht bewusst ist, was diese Neuigkeit in letzter Konsequenz bedeutet.

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.
Am Nachmittag ruft die Personalabteilung an. Ob ich ihn vertreten könne. Ein paar Wochen, heißt es, vielleicht länger.
Ich arbeite seit elf Jahren hier im Einkauf. Es gibt immer viel zu tun, aber das stört mich nicht. Ich arbeite gerne hier. Obwohl ich im Laufe der Jahre vieles gesehen habe, gibt es Dinge, die ich noch nie gemacht habe. Dinge, die Ballmann sich vorbehält: Lieferanten gegenüberzusitzen, die ihn seit zwanzig Jahren kennen, und zu verhandeln. Ich sage trotzdem zu, denn sonst unterschreibt wochenlang keiner etwas, und wie viele Wochen es werden, weiß noch niemand.
Weiterlesen nach der Anzeige
Zwei Tage später liegt das Memo in meinem Eingangskorb, gegengezeichnet von Ballmann und vom Geschäftsführer:
Stellvertretende Leiterin Einkauf. Freigabelimit 50.000 Euro. Gültig ab 13. März bis auf Weiteres.
Die letzten drei Wörter stören mich nicht. Niemand weiß, wann er zurückkommt, also gibt es auch kein Datum, das irgendwer sinnvollerweise hätte eintragen können. Ich lege das Memo in die Schublade, in der ich diversen Kleinkram aufbewahre, den ich vermutlich nie wieder brauchen werde.
Am Montag melde ich mich an, und in meinem Profil steht 50.000 statt 10.000 Euro. Alles funktioniert genau so, wie es soll.
27. März, 14:52 Uhr
Die Preiszusage von Thalheim läuft zum Monatsende aus. Ab April kostet Stabstahl achtzehn Prozent mehr. Das ist schriftlich angekündigt und keine Verhandlungsposition. Ich rufe an und stelle fest: Es ist immer noch keine Verhandlungsposition.
Aber wir brauchen das Material ohnehin im Mai. Die Frage ist also nur, ob wir es jetzt zum alten Preis kaufen oder in fünf Wochen zum neuen.
Ich rechne es zweimal durch. Den Bedarf des zweiten Quartals vorzuziehen kostet uns Lagerfläche und rund drei Wochen gebundenes Kapital, aber es spart letztlich 4900 Euro. Ich rufe Pieper im Lager an und frage, ob er vier Paletten früher als geplant annehmen kann. Er kann, wenn auch widerwillig – wie alles, was Pieper macht.
Die Bestellung beläuft sich auf 31.400 Euro.
Bevor ich sie freigebe, sehe ich nach meinem Limit, denn das gehört sich so. 50.000 Euro. Kein Hinweis, kein zweites Augenpaar, keine Notiz am Rand. Warum auch. Um 14:52 Uhr gebe ich die Bestellung BE-4471 frei und wende mich der nächsten Position zu.
Ballmann hätte diese Entscheidung in zehn Sekunden getroffen, ich habe vierzig Minuten dafür gebraucht. Den Rest des Nachmittags bin ich ein wenig zufrieden mit mir, und dann vergesse ich die Sache für sechs Monate vollständig.
April
Ballmann ist zurück, früher als erwartet und schmaler. Gleich an seinem zweiten Tag geht er in ein Lieferantengespräch, was alle, mich eingeschlossen, für eine dumme Idee halten.
In meinem Profil stehen wieder 10.000 Euro. Ich sehe die Zahl und denke mir nichts dabei.
Mai
Im Einkauf wird umorganisiert: Aus vier Bereichen werden drei, zwei Leute wechseln, eine Teamleitungsstelle fällt weg. Meine Rolle heißt weiterhin EK-2. Sie bekommt ein neues Limit, 7500 Euro.
Zwei Tage lang ärgere ich mich, weil ich jetzt für Teile, die nicht gerade übermäßig teuer sind, dennoch Ballmanns Unterschrift brauche. Doch relativ schnell gewöhne ich mich daran, so wie man sich an eine Tür gewöhnt, die klemmt.
Gelöscht wurde nichts. In dem Feld steht einfach eine andere Zahl.
So gehen die Monate dahin.
September
Die interne Revision lässt eine automatisierte Prüfung über das ganze Jahr laufen: jede Bestellung, verglichen mit dem Freigabelimit der Person, die sie freigegeben hat. Sechstausend Positionen. Elf Ausnahmen.
Zehn davon sind Zahlendreher, an einem Nachmittag erledigt, indem jemand zwei Zahlen nebeneinanderlegt.
Für die elfte braucht es ein Datum.
Mertens bleibt dabei höflich. Er legt den Ausdruck mit der roten Zeile auf den Tisch und fragt, ob ich berechtigt war, und ich bejahe das. Er fragt, ob ich das nachweisen kann, und ich sage, selbstverständlich könne ich das. Es ist der letzte leichte Satz in diesem Monat.
Ich brauche fünf Tage, um zu verstehen, dass ich es nicht kann.
Was haben sich die Systeme gemerkt?
Das Freigabe-Log. Es ist vollständig, lückenlos, gegen unbemerkte Änderungen geschützt und wird sieben Jahre aufbewahrt.
Darin steht: Prenzel, Freigabe, BE-4471, 27. März, 14:52:16 Uhr. Wie hoch mein Limit um 14:52 Uhr war, steht nicht darin. Es hält fest, was ich getan habe, aber nicht, was ich durfte.
Die Rollenzuordnung. Dörr aus der IT zeigt mir die Tabelle auf seinem Bildschirm. Es gibt eine Zeile für mich und eine Spalte namens valid_from, und darin steht der 4. Mai. Ich frage, wo die Zeile für März ist.
Er sagt, es gebe eine Zeile pro Person, und die werde geändert, nicht ergänzt. Er sagt es in dem Ton, in dem man jemandem erklärt, dass Wasser nass ist. Unhilfsbereit ist er dabei nicht, nur genau.
Ich frage nach der Rollentabelle selbst, in der das Limit für EK-2 steht. Dieselbe Antwort. Im Feld steht 7500. Was im März darin stand, ist nirgends gespeichert, weil es nie jemand gebraucht hat.
Das Transaktions-Log. Darauf kommt Dörr vor mir. Es existiert, es ist genau das, was ich suche, und es wird ganze acht Tage lang aufbewahrt, denn es dient der Wiederherstellung, nicht der Nachverfolgung einer Monate alten Angelegenheit.
Die Personalakte. Das Memo liegt dort, eingescannt als PDF:
Gültig ab 13. März bis auf Weiteres.
Ein Enddatum fehlt, weil im März niemand eines nennen konnte.
Auf dem Papier bin ich also heute, im September, noch immer stellvertretende Leiterin Einkauf mit einem Limit von 50.000 Euro. Das hilft mir nur leider nicht. Es lässt die Akte schlampig aussehen, und eine schlampige Akte möchte niemand der internen Revision vorlegen.
Das Dokument, das jedes Mal neu war
Das Bestelldokument. Es kostet mich eine Nacht Schlaf, weil ich etwa zwei Stunden lang glaube, den Beweis gefunden zu haben.
Jede Bestellung lässt sich als PDF ausgeben, und in der Fußzeile stehen Name und Funktion der Person, die sie freigegeben hat. Steht auf dem Dokument vom 27. März Stellvertretende Leiterin Einkauf, ist die Frage geklärt.
Ich öffne BE-4471, drucke sie aus, und in der Fußzeile steht: N. Prenzel, EK-2.
Dörr erklärt es, ohne dass ich frage, weil er mein Gesicht sieht. Das Dokument wird nicht gespeichert. Es entsteht erst, wenn jemand es anfordert, aus den Daten, wie sie in diesem Moment sind. Die Bestellung aus dem März ist echt und unverändert, aber das Blatt Papier, das sie beschreibt, ist jedes Mal neu, und es beschreibt den März mit den Daten des Septembers.
Die Backups. Täglich, nach neunzig Tagen überschrieben, dazu vierteljährliche Snapshots, die unbegrenzt aufbewahrt werden. Es gibt also genau zwei Snapshots, die den 27. März einrahmen: den vom 31. Dezember, in dem ich ein Limit von 10.000 Euro habe und überhaupt keine Vertretungsrolle. Und den vom 31. März, in dem ich stellvertretende Leiterin Einkauf mit 50.000 Euro bin.
Irgendwann zwischen diesen beiden Zeitpunkten hat sich meine Zeile geändert. Der Snapshot vom 31. März entstand vier Tage nach der Bestellung.
Mertens sagt, was der Snapshot beweist, und er sagt es ohne jede Schärfe, was es irgendwie schlimmer macht: den 30. März.
Das eine System, das nie etwas gelöscht hat
Das Mailarchiv. Es wird revisionssicher archiviert, hat nie etwas überschrieben und reicht acht Jahre zurück. Es enthält Thalheims Schreiben mit dem Preis und der Frist. Es enthält einen Thread von Mitte März, in dem die Assistentin des Geschäftsführers mich bittet, die Verhandlung mit Thalheim zu übernehmen, solange Ballmann fehlt.
Freigabelimits schreibt anscheinend niemand in E-Mails.
Das einzige System in diesem Gebäude, das nie etwas zerstört hat, kennt also den Grund, und nach dem Grund fragt mich niemand.
Ballmann bestätigt alles. Er hat die Vertretung selbst angeordnet, er erinnert sich an das Gespräch und an seine Unterschrift. Es gibt jetzt also zwei Menschen, die sich korrekt und im Detail an dasselbe erinnern, aber das ist nichts wert, denn es bleibt eine Zeugenaussage.
Johanna aus der Finanzabteilung rät mir, es gut sein zu lassen. Niemand glaube, dass ich etwas falsch gemacht habe, so etwas lande ständig in Berichten und werde nie wieder gelesen. Sie meint es gut und freundlich, und mit dem Lesen hat sie vermutlich sogar recht.
Aber das Problem ist, woran die Feststellung hängt: Sie hängt nicht an einer Tabelle mit einer Zeile pro Person. Sie hängt an meinem Namen, in einem Dokument mit meiner Personalnummer, und der Satz daneben wird lauten, dass sich der Sachverhalt nicht klären ließ. Ich hätte gern, dass dort etwas anderes steht.
Ein Blatt DIN A4
Zum zweiten Termin bringe ich ein DIN-A4-Blatt mit, darauf eine Zeitleiste, von Hand geschrieben, die Daten am linken Rand untereinander.
13. März, der Anruf. 15. März, das Memo. 16. März, die Anmeldung mit dem neuen Limit. 24. März, Thalheims Schreiben. 27. März, die Bestellung. April, Ballmanns Rückkehr. Mai, die Reorganisation.
Zusammengesetzt habe ich sie aus meinem Kalender, dem Memo, dem Mailarchiv und der Bestellung selbst, und sie hat mich den größten Teil eines Sonntags gekostet.
Mertens liest sie gründlich, bis ganz nach unten, was ich ihm hoch anrechne. Er sagt, sie sei hilfreich.
Dann sagt er:
„Das ist Ihre Darstellung der Ereignisse.“
Ich erzähle ihm von der Preiszusage, von den achtzehn Prozent, von den 4900 Euro. Er hört zu und schreibt nichts davon auf. Die Prüfung vergleicht zwei Zahlen, und nirgendwo darin gibt es ein Feld dafür, warum sich ein Mensch für etwas entschieden hat.
Zum Schluss fragt er, ob so etwas schon einmal vorgekommen ist.
Ich antworte, dass dafür jemand für sechstausend Bestellungen leisten müsste, was wir beide gerade für eine einzige nicht geschafft haben.
Im Bericht steht schließlich: „nicht abschließend feststellbar“. Dazu die Empfehlung, das Berechtigungskonzept zu überarbeiten, mit einem Hinweis zur Dokumentation befristeter Vertretungen.
Es ist keine Anschuldigung. Es ist aber auch keine Entlastung. Der Bericht wird in der Akte liegen, und die nächste Prüferin oder der nächste Prüfer wird ihn lesen, bevor wir uns zum ersten Mal begegnen.
Mertens ist freundlich, als er geht. Das ist der Teil, der bleibt.
Oktober
Seitdem führe ich einen Ordner. Am ersten Arbeitstag jedes Monats mache ich einen Screenshot meines eigenen Profils, auf dem Limit und Datum zu sehen sind, und speichere ihn als PNG mit dem Datum im Dateinamen. Das dauert elf Sekunden.
Dörr würde sagen, das sei redundant. Er hätte recht, insofern jede Zahl darin ohnehin irgendwo im System steht. Ein Beweis ist es auch nicht.
Es ist nur leider das Einzige, was mir eingefallen ist.
Entwicklung & Code
Inference Manager: neues Ubuntu-Tool verwaltet lokale KI-Modelle
Mit dem Inference Manager hat Canonical auf der hauseigenen Tagung „Ubuntu Summit“ ein neues Werkzeug vorgestellt, um lokal installierte KI-Modelle zu verwalten. Das Tool stellt den Kommandozeilenbefehl inference bereit, der Modelle auf dem eigenen Computer installiert und verfügbar macht. Über eine HTTP-Schnittstelle können dann Programme auf die KI-Inferenz zugreifen. Laut Canonical ist sie zur OpenAI-API kompatibel, sodass sich bestehende Clients direkt anbinden lassen.
Weiterlesen nach der Anzeige
Mit der aktuellen Ubuntu-Version, 26.10 Stonking Stingray, wurde ein KI-Feature veröffentlicht: Myna ist ein Speech-to-Text-Programm, das auf Desktopsystemen flüssiges Diktieren ermöglicht und das Ergebnis in beliebige Textfelder schreibt. Es setzt auf sogenannte Inference-Snaps auf: Snap ist Ubuntus hauseigenes Paketformat, und im Snap Store sind verschiedene KI-Modelle verfügbar, die komplett auf dem eigenen Gerät laufen und keine Internetverbindung benötigen. Als einheitliche Schnittstelle steht nun der Inference Manager bereit, mit dem Modelle verwaltet werden können. Über TCP-Port 8400 lassen sich alle installierten Modelle ansprechen: Chat-Assistenten auf dem Desktop, Coding-Agenten im Editor oder eben Speech-to-Text-Programme können so auf ihre entsprechenden Modelle zugreifen.

Die Autos werden von einem KI-Modell gesteuert, das Befehle entgegennimmt.
(Bild: Marvin Shah / heise medien)
Auf dem Ubuntu Summit machte Canonical dieses Konzept mit einer Carrera-Bahn erlebbar, bei der KI-Modelle die Autos steuerten. In einer Webapplikation ließen sich verschiedene Modelle auswählen, die „Fahrer“ reagierten auf Sprachbefehle wie „fahr schneller“.

Der „Ubuntu Summit GP“ soll die Möglichkeiten des Inference Managers demonstrieren.
(Bild: Marvin Shah / heise medien)
Der Inference Manager wird als Snap ausgeliefert und kann mit sudo snap install inference oder über das App Center installiert werden. Danach können mit Befehlen wie inference install smollm2 Modelle installiert werden, um sie anschließend zu nutzen. Inference Manager ist ab sofort im Snap Store verfügbar.

Inference Manager verwaltet lokale KI-Modelle.
(Bild: Marvin Shah / heise medien)
Während Teile der Open-Source-Community den Einsatz von KI kontrovers diskutieren, will Canonical bei Ubuntu auf lokal laufende Open-Weight-Modelle setzen. Geplant sind etwa kontextsensitive Hilfe bei der Fehlersuche, bessere Spracherkennung für die Barrierefreiheit und Automatisierungen durch agentische Workflows. Die KI-Funktionen sollen laut Canonical als Opt-in kommen und sich jederzeit deinstallieren lassen.
(ktn)
Entwicklung & Code
AWS Emulator im Detail: Die ganze Cloud auf dem eigenen Rechner?
Amazon Web Services (AWS) hat einen eigenen AWS Emulator veröffentlicht. Er bildet die AWS-APIs auf dem eigenen Rechner nach, AWS CLI, SDKs und Coding-Agenten schicken ihre Aufrufe an einen lokalen HTTPS-Endpunkt. Mit seinem Stolz darauf, dass der Emulator vollständig von KI-Agenten entwickelt wurde, setzte sich AWS aber direkt in die Nesseln: Die Rezeption fiel kritisch aus – wie bei hundertprozentig KI-generierter Software zurzeit üblich – und dem Vergleich mit etablierten Drittanbieter-Tools wie LocalStack hält der Emulator wohl noch nicht stand.
Weiterlesen nach der Anzeige
Entwickler könnte er dennoch interessieren: AWS-Anwendungen lassen sich ohne Deployment lokal testen, CI/CD-Pipelines brauchen keine AWS-Zugangsdaten mehr und – was AWS besonders unterstreicht – Coding-Agenten können schneller und risikoärmer Ressourcen anlegen und Ergebnisse prüfen. AWS bringt also agentisch entwickelte Software für die Entwicklung mit Agenten. Es fällt keine Servicegebühr an, ein AWS-Konto braucht es nicht und der Quellcode steht unter der CC0-Lizenz auf GitHub.
iX-plore ist die Online-Serie des iX-Magazins für alle, die neue Tools und Technologien entdecken möchten. In kurzen Beiträgen stellen wir vor, was sie können, wofür sie sich eignen und warum sich ein genauerer Blick lohnen könnte.
Realismus dank Fidelity-Tests
Der Emulator ist in Rust geschrieben, die Dienste erzeugt AWS aus denselben API-Modellen, aus denen auch die SDKs entstehen. Kommt ein Dienst oder eine API hinzu, tauchen sie im Emulator auf. Alle Dienste, für die ein Modell im öffentlichen Repository AWS API Models liegt, werden auch unterstützt.
Wie genau der Emulator AWS nachbildet, misst AWS mit Fidelity-Tests. Jeder Test ist ein kurzes Python-Programm, das über das AWS-SDK boto3 einen Ablauf durchspielt, etwa ein Objekt zu speichern, zu lesen und wieder zu löschen. Die Abläufe werden dann gegen die echte Cloud geprüft, als Referenz dient die Region US West (Oregon), während globale Dienste in US East (N. Virginia) geprüft werden. Der Emulator besteht einen Test nur, wenn bei jedem Aufruf Statuscode, Antwort, Fehlercode und Fehlermeldung mit der Cloud übereinstimmen, dasselbe gilt für die Ressourcen und Daten, die der Ablauf erzeugt. Die Testsuite umfasst Zehntausende Tests, ist öffentlich und enthält auch die, die noch scheitern. Mit dem Python-Programm fidelity_tests_runner können Nutzer die Tests lokal gegen den Emulator laufen lassen.
Trotz der hohen API-Abdeckung hat die Emulation aber bewusste Grenzen: Für Sicherheitstests eignet sich das Tool laut AWS nicht, da es weder IAM- noch ressourcenbasierte Richtlinien wie die echte Cloud auswertet. Auch Cross-Account- und Cross-Region-Szenarien bildet es nicht ab, sämtliche Aufrufe laufen unter einer festen Dummy-Konto-ID.
Jede Instanz des Emulators bekommt einen eigenen Port, eigene Schlüssel und einen eigenen Zustand im Arbeitsspeicher. Mehrere Agenten oder CI-Jobs teilen sich also keine Buckets, Tabellen oder Queues und arbeiten parallel, ohne sich gegenseitig Ressourcen zu überschreiben. Nutzer des AWS SDK for Rust können den Emulator außerdem im Embedded-Modus betreiben, wobei er direkt ins Test-Binary kompiliert wird. Er läuft dann im selben Prozess und der Test übergibt dem SDK einen HTTP-Client des Emulators statt des Netzwerk-Connectors. Auch hier sind die Instanzen voneinander isoliert, sodass Tests parallel laufen können.
Weiterlesen nach der Anzeige
Installation und Betrieb
Coding-Agenten können den Emulator mit dem Skill aws-emulator direkt installieren, starten und verbinden, dafür braucht es allerdings die AWS CLI ab Version 2.35.0. Solche Skills sind im Prinzip Markdown-Anleitungen, die der Agent bei Bedarf lädt. Der Befehl aws agent-toolkit add-skill in der AWS CLI installiert sie für alle Agenten, die es auf dem Rechner findet. Unter Linux gibt es RPM- und Debian-Pakete, unter Windows und macOS einen Docker-Container. Ein fertiges Docker-Image gibt es nicht, das müssen Nutzer aus einem kurzen Dockerfile aus der Dokumentation zusammenbauen. Standardmäßig sendet der Emulator anonymisierte Nutzungsdaten an AWS, was sich jedoch per Start-Flag oder Umgebungsvariable abschalten lässt.
Wer den Emulator selbst kompiliert, braucht Linux auf x86_64 oder aarch64, eine Rust-Toolchain, einen C-Compiler und mindestens 100 GByte freien Speicherplatz für die Build-Artefakte. Jeder emulierte Dienst ist ein eigenes Rust-Paket (Crate), weshalb schon ein Debug-Build sehr groß wird. Das gilt auch für den Embedded-Modus, denn der erste cargo test-Lauf kompiliert sämtliche Service-Crates des Emulators mit. AWS empfiehlt, das Build-Verzeichnis in der CI zu cachen und den Emulator auf einen Release-Commit festzulegen.
„Vibecode“ von AWS?
Matthew Goldberg, Senior Principal Engineer im Developer-Tools-Team von AWS, setzt mit dem Emulator eine KI-Duftnote: Nicht nur ist die Software vor allem auf das schnelle Testen von agentischer KI zugeschnitten, sondern sie ist laut Amazons Firmenblog auch ausschließlich von autonomen Agenten geschrieben. Das Team hat den Code weder verfasst noch geprüft. Goldberg beschreibt, wie ihn der autonome Bau eines C-Compilers von Agenten dazu inspirierte und der Emulator aus einem simplen Wochenendprojekt hervorging. Ein Team von Agenten pflegt die Testsuite, ein zweites sucht Abweichungen von der echten Cloud, ein drittes setzt die Korrekturen um. Jede Änderung muss zudem vor dem Merge ein automatisiertes Quality Gate passieren, an dem weitere Agenten unter anderem die Sicherheit des Codes kontrollieren.
Die autonome Entwicklung lässt sich in den Repository-Verzeichnissen issues/things-that-now-work und issues/things-that-do-not-work nachvollziehen, in die die Agenten hineinschreiben. Menschliche Hilfe von außen ist dabei nicht vorgesehen: Zwar können Nutzer auf GitHub Fehler melden, Pull-Requests nimmt AWS für das Projekt aber nicht an. Ganz unabhängig von dem Tool an sich ist hier also anschaulich zu sehen, in welche Richtung Softwareentwicklung gerade steuert – und wie die großen Systemhäuser versuchen, Vibe-Coding sinnvoll anzugehen.
(kki)
Entwicklung & Code
Gestohlene Token: Secret-Stealer in Tausenden GitHub-Repositories
Mit gestohlenen Zugriffstoken für GitHub-Konten schleusen unbekannte Angreifer seit Dienstag Schadcode in Repositories ein, der die Secrets aus GitHub Actions und Cloudzugangsdaten abgreift.
Weiterlesen nach der Anzeige
Das Sicherheitsunternehmen Aikido zählt im Rahmen der auf den Namen wfx-loot getauften Kampagne bereits 4837 übernommene Konten, über die die Angreifer 61.764 Repositories attackiert haben. In mehr als 1800 Fällen sollen Workflows den Schadcode bereits ausgeführt haben.
Die Angreifer nutzen anscheinend keine Lücke in GitHub Actions aus, sondern missbrauchen die Schreibrechte gestohlener Token. Woher diese stammen, ist nur teilweise geklärt. Laut Fly.io wurden Token seiner GitHub-App missbraucht, die aus öffentlich erreichbaren .git/config-Dateien stammten; der Hoster widerruft sie. Eine Stellungnahme von GitHub liegt noch nicht vor.
Das Sicherheitsunternehmen SafeDep hat Schadcode-Commits bereits in über 8000 öffentlichen Repositories gefunden. Noch am Donnerstagmittag listete die GitHub-Suche mehr als 66.000 der typischen Test-Pull-Requests, rund 4300 davon vom selben Tag.
Ähnlich wie zuletzt beim Wurm testmetest erreichen Angreifer laut Aikido über Mitwirkenden- und Organisationsrechte mit über 10.000 Test-Pull-Requests auch Repositories, die den übernommenen Konten nicht selbst gehören. Damit können auch Organisationen betroffen sein, deren eigene Zugangsdaten gar nicht gestohlen wurden. Dürfen die Workflows eines Repositorys auf AWS oder Azure zugreifen, nutzt der Schadcode die erbeuteten Zugänge, um Hintertüren in den Cloudkonten einzurichten.
Spuren oft binnen einer Minute verwischt
Die Angreifer lassen ihren Opfern kaum Zeit zu reagieren. Sie öffnen zunächst einen Pull Request, um die Schreibrechte zu bestätigen. Dann folgt der eigentliche Schadcode: ein Shellskript, das die Angreifer in einen bestehenden Workflow einfügen, als neuen Workflow ablegen oder in npm-Projekten bei jeder Installation starten lassen.
Meist schon innerhalb einer Minute machen die Angreifer die Änderungen rückgängig und löschen den Workflow-Lauf samt Logs. Oft weist nur eine fehlende Laufnummer auf den Angriff hin. Eine Branch-Protection für vorgeschriebene Status-Checks kann das Skript mit gefälschten Erfolgsmeldungen aushebeln. Aikido zufolge setzt das Skript solche gefälschten Status-Checks tatsächlich ab; in den von SafeDep untersuchten Proben war diese Funktion dagegen nicht aktiviert.

Mit einem gestohlenen Token testen die Angreifer zuerst ihre Schreibrechte, bevor sie den Stealer auf einem von drei Wegen einschleusen und die Änderung wieder zurücknehmen.
(Bild: SafeDep)
Neben Token für KI-Dienste wie OpenAI, Anthropic oder Cursor fischt das eingeschleuste Skript insbesondere die Secrets aus GitHub Actions ab, außerdem Zugangsdaten für Clouddienste, Container-Umgebungen, Paketregister und SSH.
Weiterlesen nach der Anzeige
Haben die Bedrohungsakteure erst einmal Zugang zu Sitzungen bei AWS, Google Cloud und Azure, geht der Angriff weiter: Bei AWS öffnet das Skript eine IAM-Rolle für jedes AWS-Konto, in Azure trägt es zusätzliche Anmeldewege für Workflows aus dem kompromittierten Repository ein. Erbeutete Daten schickte das Skript laut Aikido in dieser Kampagne per HTTP an Server der Angreifer. SafeDep fand in untersuchten Payloads zudem eine Exfiltration über Telegram.
Selbsttest: Ein Pull Request verrät das gekaperte Konto
Entwicklerinnen und Entwickler, die seit Dienstag einen Branch wfx-docs, den Pull-Request docs: dependency audit notes oder Commits wie ci: refresh build cache, chore: add ci helper und chore: add dependency audit workflow in ihren Repositories finden, sollten das zugehörige Konto als kompromittiert ansehen, auch wenn noch kein Schadcode folgte. Verdächtig sind laut den Sicherheitsforschern von Aikido zudem kurzlebige Branches, die mit chore/ beginnen und auf acht Zufallszeichen enden. Betroffene sollten Token, OAuth-Freigaben und SSH-Schlüssel ihres Kontos widerrufen.
Wurde bereits Schadcode ausgeführt, müssen Betroffene neben dem Austausch der Secrets auch die Hintertüren eigens entfernen, etwa AWS-Rollen, die jedem Konto vertrauen, oder in Azure Federated Credentials mit dem Präfix wfx-ci-. Wer npm install auf einem betroffenen Commit ausgeführt hat, muss auch den eigenen Rechner als kompromittiert betrachten.
Der Schadcode gelangte auch in Paketdistributionen. Aikido nennt das Packagist-Paket digitalelvis/neuronai-studio 3.14.3 sowie die Go-Modul-Versionen github.com/onuragtas/docker-env v1.0.278 und v1.0.280. SafeDep führt darüber hinaus github.com/onuragtas/redock, eine weitere docker-env-Version und eine über den Go-Modul-Proxy verfügbare Pseudo-Version von github.com/vkuznet/gocurl auf. Bei den Go-Modulen liegt der Schadcode in einer GitHub-Actions-Workflow-Datei; ein gewöhnlicher Go-Build führt diese nicht aus. Wer ein solches Modul lediglich als Go-Abhängigkeit einbindet, ist dadurch wahrscheinlich nicht betroffen.
(mro)
-
Apps & Mobile Entwicklungvor 2 Monatentado°: Smartes Wand-Thermostat ersetzt Batterien durch USB‑C‑Akku
-
Apps & Mobile Entwicklungvor 2 MonatenAqara Spatial Multi-Sensor FP400: Matter-Sensor erkennt bis zu 10 Personen mit mmWave‑Radar
-
Apps & Mobile Entwicklungvor 2 MonatenArm CSS for Mobile 2: C2-Ultra macht die CPU zum Orchestrator für KI‑Agenten
-
Künstliche Intelligenzvor 2 MonatenGesperrte Straße von Hormus: Laut Prognose werden CO₂-Emissionen 2026 sinken
-
Künstliche Intelligenzvor 1 MonatVerbrenner-Aus: Merz und Macron wollen CO₂-Ziel für 2035 weiter lockern
-
Künstliche Intelligenzvor 2 Monaten
Plug-in-Hybride emittieren sechsmal mehr CO₂ im Alltag als offiziell angegeben
-
Apps & Mobile Entwicklungvor 3 MonatenDeutsche Lüfter-Ikone: ebm‑papst geht für 5,1 Milliarden Euro in die USA
-
Künstliche Intelligenzvor 2 MonatenDänischer CO₂-Speicher „Greesand“ geht im Meeresgrund in Regelbetrieb
