Entwicklung & Code
ODF statt Lock-in: Wer kontrolliert unsere Dateien?
Wer kontrolliert unsere Dokumente – und wer entscheidet darüber, ob sie auch in zehn oder zwanzig Jahren noch lesbar, bearbeitbar und unabhängig von einem einzelnen Anbieter nutzbar sind? Für Italo Vignoli von der Document Foundation ist die Antwort klar: Die Debatte um digitale Souveränität beginnt nicht bei der Wahl einer Office-Suite, sondern beim Dateiformat. Im Gespräch erklärt er, warum er DOCX, XLSX und PPTX als strategisches Lock-in betrachtet, weshalb ODF aus seiner Sicht weit mehr ist als eine technische Alternative – und warum Behörden, Unternehmen und private Nutzer ihre Dokumentstrategie grundlegend überdenken sollten.
Weiterlesen nach der Anzeige
Der TDF-Blog war lange vor allem für Nachrichten rund um LibreOffice bekannt. Warum habt ihr gerade jetzt eine Reihe über offene Formate, Standards und digitale Souveränität gestartet?
Der TDF-Blog wurde eingerichtet, um über sämtliche Aktivitäten des Projekts zu berichten – nicht nur über LibreOffice, sondern auch über das Dokumentformat ODF, die von Document Liberation entwickelten Filter für ältere Formate, die Unterstützung politischer Initiativen zugunsten von FOSS sowie groß angelegte Migrationsprojekte. Die Liste ist tatsächlich sehr lang.
Die Idee für die aktuelle Artikelserie entstand im Vorfeld des zwanzigsten Jahrestags der Verabschiedung von ODF als OASIS-Standard im Mai 2025 – als Würdigung dieses außerordentlich wichtigen Meilensteins für FOSS. Das äußerst positive Feedback auf die ersten Artikel, die von verschiedenen Medien kommentiert und aufgegriffen wurden, ermutigte uns, die Reihe fortzusetzen und zudem auf weitere Themen auszuweiten, etwa auf digitale Souveränität – die eng mit ODF verbunden ist – und proprietäre Formate.
Die Anzahl der auf den Inhalten dieser Beitragsreihe beruhenden Artikel sowie das Interesse zahlreicher Journalisten an den behandelten Themen haben uns dazu bewogen, weiterzumachen – ursprünglich hatten wir eine Reihe von etwa zwanzig Artikeln vorgesehen – und uns an Diskussionen über digitale Souveränität zu beteiligen, nicht zuletzt, weil dieses Thema zu einem gemeinsamen Anliegen geworden ist.
Warum beginnt die Debatte über freie und unabhängige Bürosoftware bei Dateiformaten und nicht bei der Wahl der Anwendung?
In einer idealen Welt gäbe es ausschließlich Open-Source-Softwarelösungen, die sowohl bei Komponenten als auch bei Dokumentformaten nur offene Standards nutzen. Leider ist die Welt, in der wir leben, alles andere als ideal. Denn seit Jahrzehnten wurde die Kontrolle über Technologie völlig unkritisch in die Hände von Big Tech gelegt – mit den Folgen, die wir alle kennen.
Zu diesen Folgen zählt genau jenes proprietäre Format, das sich als offener Standard ausgibt und uns dazu zwingt, die Diskussion bei den Formaten statt bei den Anwendungen zu beginnen. Tatsächlich verwenden selbst die meisten Open-Source-Office-Suiten – oder jene, die sich als solche bezeichnen – dieses proprietäre Format nativ. Damit vergrößern sie Microsofts Kontrolle über Dokumente, denn Microsoft definiert das Format und entscheidet somit über dessen Interoperabilität.
Weiterlesen nach der Anzeige
„Open Source“, „offenes Format“ und „offener Standard“ werden häufig gleichbedeutend verwendet. Worin liegt der Unterschied – und warum sollte er nichttechnische Nutzer interessieren?
Die drei Begriffe unterscheiden sich grundsätzlich, weil sie sich auf völlig verschiedene Dinge beziehen: „Open Source“ bezeichnet Software, deren Quellcode verfügbar gemacht wird, damit er untersucht, verändert, verbessert und weiterverbreitet werden kann. Ein „offenes Format“ bezeichnet ein Dokumentformat, das transparent entwickelt, gut dokumentiert, versionskontrolliert und für kompetente Entwickler leicht implementierbar ist. Ein „offener Standard“ bezieht sich auf Elemente – Hardware, Software und mehr –, deren Eigenschaften eine einfache Wiederverwendung ohne Einschränkungen oder Begrenzungen ermöglichen.
LibreOffice ist Open Source, weil seine Copyleft-Lizenz MPL Nutzung, Untersuchung, Veränderung und Verbreitung erlaubt. ODF ist ein offenes Format, weil es von einer unabhängigen Organisation öffentlich und transparent entwickelt, entsprechend der jeweiligen Version konsistent dokumentiert, versionskontrolliert und leicht implementierbar ist. ODF ist zugleich ein offener Standard – teilweise aus denselben Gründen, aus denen es ein offenes Format ist, und teilweise, weil es andere offene Standards wiederverwendet und keinerlei proprietäre Elemente enthält.
DOCX, XLSX und PPTX werden fast überall verwendet. Wo genau entsteht dadurch aus Ihrer Sicht eine problematische Abhängigkeit von einzelnen Anbietern?
DOCX, XLSX und PPTX sind proprietäre Formate, weil sie eine Version des Formats verwenden, die als „Transitional“ bezeichnet wird, da sie weiterhin mit den proprietären Formaten DOC, XLS und PPT verknüpft ist. Diese Variante sollte 2010 durch eine Standardversion namens „Strict“ ersetzt und anschließend vollständig abgeschafft werden – gerade weil sie proprietär war.
Damals setzte ISO auf Microsoft, das all dies bei der Genehmigung des Formats zugesichert hatte. Von einer Standardisierung kann dabei in keiner Weise gesprochen werden, denn kaum etwas ist weiter von einem Standard entfernt als das Microsoft-Format – einschließlich der „Strict“-Version. ISO glaubte damals nicht jenen, die darin eine Strategie sahen, Zeit zu gewinnen und sicherzustellen, dass sich nichts ändert, damit das Microsoft-Office-Format dauerhaft proprietär bleibt. Die Geschichte hat uns recht gegeben.
DOCX, XLSX und PPTX – die ich jetzt unter dem offiziellen Namen des Formats, OOXML, zusammenfassen werde – sind unabhängig von der Software, dem Anwendungsfall oder dem Nutzertyp ein Problem. Proprietäre Formate sind immer ein Problem, weil sie von einem einzigen Unternehmen auf Grundlage eigener Geschäftsstrategien definiert werden, die nie mit den Interessen der Nutzer übereinstimmen.
Darüber hinaus sind diese Formate gezielt darauf ausgelegt, einen Lock-in zu erzeugen, der äußerst schwer zu erkennen ist, sofern man die technischen Eigenschaften des Formats nicht eingehend untersucht. Selbst die Softwareunternehmen, die sich entschieden haben, das OOXML-Format nativ zu unterstützen, sind sich dessen nicht bewusst, weil sie es nicht untersucht haben. Sie verwenden also ein Format, das ihre eigenen Nutzer bindet – allerdings zum Vorteil Microsofts, nicht zu ihrem eigenen.
Ich verstehe vollkommen, dass all dies wie Science-Fiction klingt. Leider handelt es sich jedoch um eine Realität, die selbst dann nicht erfasst wird, wenn man sie einfach – oder besser: so einfach wie möglich – erklärt. Leider gibt es keinen wirklich einfachen Weg, das Problem zu erläutern, denn es wurde bis ins kleinste Detail so konzipiert, dass es äußerst kompliziert ist.
Wie gut funktioniert die tägliche Arbeit mit ODF heute tatsächlich? Bei welchen Dokumenttypen ist der Wechsel unkompliziert, und wo sollten Nutzer realistischerweise Schwierigkeiten erwarten – etwa bei Makros, spezialisierten Vorlagen oder komplexen Tabellen?
ODF ist hinsichtlich der Funktionalität des Formats genauso gut wie OOXML. Es kann daher für jede Aufgabe und in jeder Anwendung problemlos eingesetzt werden und beeinträchtigt die Interoperabilität von Dateien nicht, da es vollständig dokumentiert ist.
OOXML hingegen wurde bewusst so konzipiert, dass es Interoperabilitätsprobleme verursacht. Es ist auch nicht so dokumentiert, dass dieses Problem entschärft würde, da sich die Formatspezifikationen durch regelmäßige Sicherheitsupdates auf nicht dokumentierte und unsichtbare Weise verändern.
Folglich werden Interoperabilitätsprobleme durch OOXML und nicht durch ODF verursacht. Daher sollten die Kosten dafür von OOXML-Nutzern getragen werden, nicht von ODF-Nutzern. Zudem gilt: Wenn ein Dokument im OOXML-Format korrekt erstellt wurde, lässt es sich auch im ODF-Format korrekt öffnen.
Ich nutze seit Jahren Linux und öffne daher alle OOXML-Dateien, die ich erhalte, mit LibreOffice. Es konvertiert sie sofort in das native ODF-Format. Dabei hatte ich noch nie ein Problem. Wenn ich einer Kontaktperson eine Datei im OOXML-Format senden muss, konvertiere ich die ODF-Datei in OOXML. Auch in diesem Fall hatte ich noch nie ein Problem. In meinem Beruf verfasse ich sehr viele Dokumente – wir sprechen von Tausenden Dateien.
Natürlich werden viele Dateien eher unsystematisch erstellt – und Sie können sich kaum vorstellen, wie kreativ Menschen dabei sein können. Deshalb öffnen sie sich in beide Richtungen nicht korrekt.
Meiner Erfahrung nach braucht es weniger Zeit, eine Datei zu korrigieren, als sich über Inkompatibilität zu beklagen, auch wenn sich die meisten Nutzer für Letzteres entscheiden. Solange wir jedoch ein Format haben, das gezielt dafür entwickelt wurde, Interoperabilitätsprobleme zu verursachen, wird sich die Situation nicht grundlegend ändern.
Makros wiederum sind ein komplett eigenes Problem, weil sie in keiner Weise zur Welt der Standards gehören. Eine ODF-Datei mit Makros ist mit einer OOXML-Datei mit Makros identisch – sie ist also mit jedem Standard unvereinbar, sofern keine neutrale Sprache wie Python verwendet wird.
Makros gehören zur ersten Generation von Office-Suiten und ergeben heute nur noch in sehr wenigen Fällen Sinn. Das liegt auch daran, dass viele dieser Funktionen inzwischen direkt in die Software integriert sind. Außerdem zählen sie zu den wichtigsten Sicherheitslücken und sollten deshalb niemals eingesetzt werden – insbesondere nicht in Umgebungen, die besonders stark von Angriffen bedroht sind.
Viele Organisationen meinen: „Wir würden gerne offene Formate nutzen, aber unsere Kunden und Partner schicken uns einfach Microsoft-Dateien.“ Wie lautet Ihre pragmatische Antwort darauf?
Die pragmatische Lösung ist zugleich die einfachste. Es handelt sich um die Methode, die wir im Migrationsprotokoll empfehlen – einem Dokument, das TDF auf Grundlage bewährter Verfahren erstellt hat. Diese haben sich in Dutzenden Projekten bewährt, darunter groß angelegte Vorhaben in Schleswig-Holstein und beim österreichischen Verteidigungsministerium.
Jedes eingehende Dokument sollte sofort in das ODF-Format konvertiert werden, um sämtliche Vorteile des Standardformats zu nutzen. Anschließend sollte es als zweite Kopie im OOXML-Format gespeichert werden, um die Interoperabilität mit proprietären Formaten sicherzustellen. Das dauert nur wenige Sekunden, und Speicherplatz ist sicherlich kein Problem.
Darüber hinaus ist das ODF-Format nicht nur wesentlich robuster als OOXML. In den sehr seltenen Fällen, in denen eine Datei beschädigt ist, ermöglicht es aufgrund der Eigenschaften des Standardformats und der perfekt lesbaren XML-Datei, sämtliche Inhalte wiederherzustellen. Eine beschädigte OOXML-Datei ist dagegen praktisch nicht wiederherstellbar.
Deutschland will offene Formate wie ODF bis 2027 stärker zum Standard in der öffentlichen Verwaltung machen. Was müsste passieren, damit dieses politische Ziel im Alltag ankommt?
Jede Migration zum Standardformat ODF ist möglich, sofern sie strukturiert angegangen wird – mit einem Projekt, das sowohl technische Aspekte, die sich leicht lösen lassen, als auch Aspekte der Umsetzung berücksichtigt, nämlich Prozesse und Nutzer.
Das Problem besteht leider darin, dass der Wechsel von OOXML zu ODF auch einen Wechsel von Microsoft Office oder einem seiner Klone zu LibreOffice erforderlich macht, weil die ODF-Unterstützung in diesen Programmen sehr schlecht ist, wie im jüngsten Artikel unserer Reihe erläutert wurde.
Diese Migration der Anwendungen fügt eine weitere Ebene der Komplexität hinzu. Wäre die ODF-Unterstützung ordentlich statt katastrophal, wäre die Migration des Formats allein kein Problem und würde lediglich die Anpassung einiger OOXML-basierter Prozesse erfordern.
Leider ist die schlechte ODF-Unterstützung Teil der Lock-in-Strategie von Microsoft und den Entwicklern seiner Klone. Wir können daher nicht erwarten, dass sie sich verbessert – selbst angesichts von Entscheidungen wie jener der deutschen Bundesregierung. Diesen Lock-in aufzugeben würde nämlich bedeuten, einen Marktanteil im Wert von fast 30 Milliarden US-Dollar nicht mehr zu schützen, bei einem Nettogewinn von mehr als 90 Prozent dieser Summe.
Warum scheitern ODF-Einführungen trotz klarer politischer Entscheidungen so oft: an der Technik, an Beschaffung, Schulungen und Gewohnheiten – oder an den Machtstrukturen des Softwaremarkts?
Tatsächlich haben sich die meisten Migrationen von Microsoft Office zu LibreOffice nie mit der Frage der Dokumentformate befasst, weil sie nicht von dem Ziel digitaler Souveränität angetrieben waren, sondern ausschließlich von den Softwarekosten. Deshalb haben Organisationen fast immer das OOXML-Format beibehalten.
Erst in den vergangenen Jahren hat die stärkere Fokussierung auf digitale Souveränität dazu geführt, dass Organisationen auch eine Migration von OOXML zu ODF in Betracht ziehen. Dies ist im Migrationsprotokoll bereits vorgesehen. Dabei handelt es sich zwar um einen zusätzlichen Schritt, der jedoch kein Problem darstellt.
Frühere gescheiterte Migrationen von proprietärer zu Open-Source-Software waren nie auf technische Probleme zurückzuführen – selbst wenn versucht wurde, sie als technische Probleme darzustellen. Im Fall München wurde beispielsweise das Dokument, das die technischen Probleme auflistete, von HP, einem Microsoft-Partner, erstellt und enthielt Behauptungen, die an Lächerlichkeit grenzten. Ähnliches geschah in Italien bei der Migration der Stadt Pesaro und der Provinz Bozen.
Es wäre außerdem sinnlos, die Tatsache zu ignorieren, dass die Unternehmen, die weltweit – und auch in Europa – am meisten für Lobbyarbeit ausgeben, die Big-Tech-Konzerne sind. Allein auf EU-Ebene belaufen sich ihre Budgets auf Millionen Euro, ganz zu schweigen von den Budgets der einzelnen Länder, die nicht öffentlich bekannt sind. In Brüssel, wo es Daten gibt, kommen auf jedes Mitglied des Europäischen Parlaments mehr als zwei Lobbyisten. Es ist ein ungleicher Kampf zwischen Open-Source-Software und proprietärer Software.
Machen Cloud-Dienste und KI-Werkzeuge offene Formate weniger wichtig, weil einzelne Dateien an Bedeutung verlieren – oder wichtiger, weil die Kontrolle über Inhalte und Metadaten schwieriger wird?
Dokumente bleiben Dokumente, auch in der Cloud und bei der Nutzung von KI-Werkzeugen. Was die meisten Menschen nicht erkennen, ist, dass sich das Dokument im Laufe der Jahre von einem einfachen Blatt Papier zu einer ausführbaren Datei entwickelt hat. Diese enthält die Anweisungen, die eine Software benötigt, um den Inhalt der Datei auf dem Bildschirm darzustellen. Sie ist daher nicht mehr so „unschuldig“ wie ihre gedruckte Version – jenes einfache Blatt Papier, aus dem sie hervorgegangen ist.
Deshalb ist das Format von Dokumenten wichtiger denn je. Der Unterschied zwischen einem standardisierten, offenen Format und einem proprietären Format ist vergleichbar mit dem Unterschied zwischen Open-Source-Software und proprietärer Software. Bei Dokumenten betrifft dieser Unterschied die Verwaltung der Inhalte: Beim Standardformat ist sie transparent dokumentiert, beim proprietären Format dagegen verschleiert dokumentiert und verwendet Verweise, die nur dem Autor bekannt sind – nämlich Microsoft.
Um eine leicht verständliche Parallele zu ziehen: Es ist, als läge der Schlüssel zu unserer Haustür in den Händen einer externen Instanz, die entscheiden kann, ob und wann wir unser eigenes Zuhause betreten dürfen. Bei einem Standardformat bleibt der Schlüssel immer in den Händen des Eigentümers.
Gibt es aus Ihrer Sicht einen allgemein akzeptierten Kriterienkatalog dafür, wann ein Format wirklich offen ist – oder bewertet die TDF Formate nach eigenen Maßstäben?
Es gibt mehrere Kriterien dafür, wann ein Format wirklich offen ist, auch wenn eine einheitliche Definition fehlt. Im TDF-Blog haben wir deshalb eine Definition veröffentlicht, die wir bei TDF verwenden.
Ihre Frage hat jedoch das Problem der fehlenden einheitlichen Definition deutlich gemacht. Deshalb werde ich auf der kommenden LibreOffice-Konferenz in Pordenone einen Vortrag halten, in dem ich gemeinsame Kriterien für eine solche Definition vorschlage. Mit diesem Thema beschäftige ich mich bereits, denn das Fehlen einer einheitlichen Definition sorgt auf dem Markt für einige Verwirrung.
Wenn eine Verwaltung morgen beginnen wollte: Was wäre die zentrale erste Maßnahme, die Sie unabhängig von Softwarepolitik und Lobbydruck empfehlen würden?
Für öffentliche Verwaltungen gibt es meines Erachtens ein zentrales Problem zu lösen, das in unserem Blogbeitrag „What is Digital Sovereignty?“ beschrieben wird: sicherzustellen, dass nichts Wesentliches verloren gehen kann.
Das entscheidende Wort ist dabei „wesentlich“. Eine Institution muss nicht selbst Eigentümerin der Cloud sein. Sie muss aber sicher sein, dass ihre Daten nicht ebenfalls verschwinden, wenn ein Anbieter morgen vom Markt verschwindet. Sie muss proprietäre Werkzeuge nicht verbieten. Sie muss jedoch gewährleisten, dass das, was sie diesen Werkzeugen anvertraut – ihre Akten, Verträge und Bürgerdaten –, auch für andere als den Anbieter, der das Werkzeug verkauft hat, lesbar, übertragbar und rekonstruierbar bleibt.
Souveränität bedeutet nicht, eine Mauer um den eigenen Besitz zu errichten. Sie ist eine Garantie dafür, aus einer Abhängigkeit aussteigen zu können.
Um dieses Ziel zu erreichen, kann die technische Entscheidung im Kern nur eine sein: Technologien und Werkzeuge zu wählen, die nicht von einem einzigen Unternehmen kontrolliert werden – es sei denn, sie sind vollständig Open Source. Natürlich kann diese Entscheidung angesichts der Entwicklungen der vergangenen Jahrzehnte äußerst schwierig und herausfordernd sein.
Es gibt öffentliche Verwaltungen, deren Infrastruktur auf Lösungen verschiedener Anbieter beruht, und andere, deren Infrastruktur von einem einzigen Anbieter abhängt. Erstere setzen in der Regel bereits zumindest teilweise auf Open Source, während Letztere meist ausschließlich proprietäre Software nutzen.
Der Weg zur digitalen Souveränität ist schwierig, weil dieses Konzept über zu viele Jahre hinweg ignoriert wurde. Es ist ironisch, dass heute alle über digitale Souveränität sprechen, während dieselben Akteure früher die Forderungen von Open-Source-Befürwortern ignoriert haben. Wir verwendeten damals zwar nicht den Begriff „digitale Souveränität“, vertraten aber bereits dasselbe Konzept.
Wenn Sie Nutzern und Organisationen nur eine einzige Regel für den langfristigen Umgang mit wichtigen Dokumenten geben könnten: Welche wäre das?
Die Regel ist sehr einfach: „aktive“ Dokumente – also solche, die bearbeitet werden müssen – sollten im ODF-Format verwaltet werden. „Historische“ Dokumente – also solche mit Referenzinformationen, die nicht verändert werden dürfen – sollten im PDF-Format verwaltet werden. Natürlich ist es auch möglich, alle Dokumente im ODF-Format zu speichern.
Herr Vignoli, vielen Dank für die Antworten!
Das Interview wurde auf Englisch geführt. Das Original findet sich hier.
(fo)
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
