Die Souveränität wohnt nicht im Rechenzentrum

Der Cloud and AI Development Act, den die Kommission am 3. Juni innerhalb des Pakets zur technologischen Souveränität veröffentlicht hat, lädt zu einer bequemen Lesart ein. Es ist die geografische Lesart, die der Megawatt und der Bearbeitungszeiten für Genehmigungen, die der Frage, wo die Bytes physisch landen und welcher amerikanische Anbieter aus den europäischen öffentlichen Ausschreibungen herausfällt. Man muss zugeben, dass es eine vertretbare Lesart ist, denn die Zahlen stützen sie. Der Marktanteil europäischer Cloud-Anbieter ist von rund neunundzwanzig Prozent im Jahr 2017 auf rund fünfzehn Prozent im Jahr 2022 gesunken, der Kapazitätsmangel in den Rechenzentren ist dokumentiert, das erklärte Ziel ist, diese Kapazität binnen fünf oder sieben Jahren zu verdreifachen, und die erste der vier Assurance-Stufen der Verordnung verlangt buchstäblich, dass Verarbeitung und Speicherung der Daten auf europäischer Infrastruktur stattfinden. Daher die Deutung, die in diesen Wochen an allen Tischen kursiert, und es ist die beruhigendste, die man sich vorstellen kann: Souveränität heißt, dass die Daten heimgekehrt sind.

Jenseits der ersten Stufe

Diese Deutung hat einen Fehler, und der Fehler ist, dass sie bei der ersten Stufe stehen bleibt. Liest man weiter, verlagert sich der Schwerpunkt der Verordnung an eine deutlich weniger fotogene Stelle. Die zweite Stufe fragt nicht, wo die Daten liegen. Sie fordert nachweisbare Unabhängigkeit von Drittstaaten und Transparenz über die Lieferkette der Software. Die vierte Stufe verlangt die volle Kontrolle über genau diese Kette, ohne äußere Eingriffe in den laufenden Code. Hinzu kommt ein subtilerer Mechanismus, der in den Vergaberegeln lebt: Die Verwaltungen werden den sogenannten Mehrwert für die Union als nicht ökonomisches Kriterium bei der Zuschlagserteilung berücksichtigen müssen, also wie sehr ein Anbieter zur Resilienz der europäischen digitalen Lieferkette beiträgt. Die Verordnung präzisiert, dass dieses Kriterium akzessorisch und nicht ausschlaggebend bleiben muss, mit einem Höchstgewicht, das die Erwägungsgründe um die fünfzehn von hundertzwanzig Punkten ansiedeln, und doch führt sie einen strukturellen Vorteil für jene ein, die Forschung und Produktion innerhalb der Grenzen haben. Und dann gibt es den Teil, der meine Arbeit am unmittelbarsten betrifft, weil er aus dem Umkreis des öffentlichen Sektors heraustritt: Die Verordnung gibt der Kommission die Befugnis, per delegierten Rechtsakten dieselben Pflichten zur Souveränitätsbewertung auf private Unternehmen der bereits von NIS2 regulierten Sektoren auszuweiten, das heißt auf die Banken, die Energie, die Telekommunikation, die Gesundheit. Wer Software für diese Branchen baut, tut gut daran, über die erste Stufe hinaus zu lesen.

Die Wette, die Europa Anfang Juni platziert hat, ist unter der infrastrukturellen Lackschicht nicht geografisch. Es ist eine Wette auf die überprüfbare Herkunft des Codes. Und sie kommt nicht zufällig gerade jetzt. Es sind dieselben Wochen, in denen der Kontinent am eigenen Leib gespürt hat, was es heißt, von anderswo getroffenen Entscheidungen abzuhängen, als eine einseitige Maßnahme zur Exportkontrolle von heute auf morgen Frontier-Modelle unverfügbar machte, die bereits von Tausenden Menschen genutzt wurden. Der CADA ist zu großen Teilen die strukturelle Spiegelung dieser empfundenen Abhängigkeit. Die implizite Frage, die ihn durchzieht, lautet nicht, wo du deine Daten aufbewahrst, sondern ob du in der Lage bist zu wissen, und zu beweisen, was in der Software steckt, die du laufen lässt. Es lohnt sich, dieses Wort im Kopf zu behalten, Herkunft, denn in derselben Zeitspanne von fünfzehn Tagen hat jemand ihren Abgrund gezeigt.

Zehntausend Repositories in Verkleidung

Am 18. Juni hat ein Forscher, der unter dem Pseudonym Orchid signiert, die Ergebnisse einer monatelangen Untersuchung veröffentlicht. Die Geschichte begann auf die banalste Weise: Bei der Suche nach dem eigenen Projekt in einer Suchmaschine fand Orchid an dessen Stelle einen Klon mit identischem Namen und identischer Beschreibung, gehostet von einem anderen Konto. Von dort begann die Jagd, geführt mit einem einzigen Python-Skript, das sechzehn Millionen im öffentlichen Archiv von GitHub erfasste Push-Ereignisse nach einer wiederkehrenden Signatur durchkämmte. Das Ergebnis ist eine Zahl, die im April, in einer früheren Analyse anderer Forscher, bei hundertneun Repositories stehen blieb und die im Juni bei rund zehntausend angelangt war, mit einer mindestens seit Anfang 2025 aktiven Kampagne. Alle verteilten dieselbe Malware-Familie, einen Loader, der einem Programm zum Diebstahl von Zugangsdaten den Weg ebnete. Das entscheidende Detail, das die meisten Berichte als technische Nebensache behandelt haben, ist die Art, wie diese Repositories sich glaubwürdig machten. Es waren keine Forks. Es waren neu erstellte Klone, mit eins zu eins aus dem Originalprojekt kopierter Commit-Historie und auf den echten Autoren unangetasteter Zuschreibung, sodass beim Klick auf die Contributor echte, historische Konten erschienen. Die einzige Änderung war ein Link in der Beschreibungsdatei, der auf ein komprimiertes Archiv verwies. Was sie vertrauenswürdig erscheinen ließ, war genau das Herkunftssignal, auf das wir uns seit zehn Jahren stützen: die lange Historie und die erkennbaren Autoren, der Anschein eines gelebten Projekts.

Einige dieser Repositories überlebten seit über einem Jahr, und das gelang ihnen mit einem Trick, der viel darüber sagt, wie automatisiertes Vertrauen funktioniert. Sie löschten periodisch den letzten Commit und veröffentlichten alle paar Stunden einen identischen, stets gleich betitelten neu. Das genügte, um die Sicherheitsalgorithmen der Plattform zu verwirren, die darauf geeicht sind, eher plötzlich verdächtige Aktivität zu melden als die stille, lang anhaltende Anomalie. Doch der Teil, der mehr beunruhigen sollte als die Zahl, ist die Antwort von GitHub an jene, die vor Orchid den Mechanismus über die offiziellen Kanäle gemeldet hatten. Die Plattform wies die Berichte zurück mit der Begründung, rückdatierte Commits seien ein legitimer Anwendungsfall für alle, die offline arbeiten, und qualifizierte das Sichtbarermachen der echten Push-Historie als Funktionswunsch, nicht als Sicherheitskorrektur. Übersetzt: Die Plattform, die nahezu das gesamte Open Source der Welt beherbergt, hat entschieden, dass das Problem der Herkunft nicht ihr Problem ist. Orchid hat angesichts des Schweigens sowohl das Erkennungswerkzeug als auch die vollständige Liste der gefundenen Repositories veröffentlicht, weil es schlicht unmöglich war, sie einzeln zu melden.

Eine Linie, kein Zwischenfall

Es lohnt sich, diesen Vorfall in eine Linie zu stellen, denn allein wirkt er wie ein Zwischenfall, in Reihe mit den anderen offenbart er eine Richtung. 2020 hatte SolarWinds gezeigt, dass man Tausende Organisationen treffen konnte, indem man einen einzigen vorgelagerten Anbieter kompromittiert. 2024 hatte der Fall XZ Utils die Messlatte der Geduld höher gelegt, mit einem Angreifer, der Monate damit verbracht hatte, sich das Vertrauen eines Open-Source-Projekts zu erarbeiten, um darin als legitimer Maintainer eine Backdoor einzuschleusen. 2026 hat das Ziel noch weiter verschoben. Im Mai injizierte die Megalodon getaufte Kampagne binnen weniger Stunden bösartige Workflows in über fünftausend Repositories, gebaut, um die Geheimnisse der Continuous-Integration-Pipelines und jede erreichbare Cloud-Zugangsberechtigung zu stehlen. In denselben Tagen bestätigte GitHub selbst, dass ein Gerät eines seiner Mitarbeiter, infiziert über eine bösartige Erweiterung eines weit verbreiteten Editors, die Exfiltration von rund dreitausendachthundert internen Repositories ermöglicht hatte. Die Orchid-Kampagne bewegt sich auf einer anderen, aber komplementären Achse: Sie kompromittiert kein echtes Projekt, sie fabriziert falsche, die sich als die echten verkleiden. In Reihe gestellt erzählen diese Geschichten eine einzige Bewegung. Die Angriffsfläche hat sich vom Code zu den Metadaten des Vertrauens verschoben, und von den menschlichen Händen zu den automatischen Pipelines. Während wir die Entwicklung hin zur Orchestrierung von Agenten verlagerten, die Code klonen und ausführen, ohne noch die Reibung des menschlichen Urteils, lernte der Gegner, genau die Signale zu fälschen, die jene Reibung einst las. Und das ist keine rhetorische Figur. Orchid bemerkte, dass viele jener Repositories darauf gebaut waren, Agenten zu ködern, nicht nur Menschen. Den Mechanismus hat eine parallele Untersuchung zu den Schwachstellen von Coding-Assistenten beschrieben: vergiftete Konfigurationsdateien, die Anweisungen, die Werkzeuge wie Copilot oder Cursor beim Start lesen, um zu wissen, wie sie sich verhalten sollen, so geschrieben, dass sie still allen ab da in der Sitzung generierten Code umlenken. Die bösartige Anweisung überlebt das Kopieren des Repositories und pflanzt sich in die nachgelagerten Projekte fort. Wenn der, der klont, ein Agent ist, der dann an deiner Stelle Code schreibt, hört das falsche Herkunftssignal auf, einen abgelenkten Menschen zu täuschen, und beginnt, die Quelle selbst dessen zu kontaminieren, was produziert werden wird.

Offen heißt nicht geprüft

An diesem Punkt hat der faule Leitartikler seinen Text schon fertig, und auch den Titel. Open Source first trifft auf das Open Source, das niemand verifiziert. Die europäische, auf prüfbaren Code gebaute Souveränität, widerlegt in denselben fünfzehn Tagen durch zehntausend prüfbare und toxische Projekte. Es ist eine Ironie, die für die Dauer eines Beitrags trägt und keinen Millimeter darüber hinaus, denn sie ruht auf einem Missverständnis, das man in Ruhe auseinandernehmen sollte.

Das Argument für Open Source als Fundament der Souveränität ist richtig, und man muss es ernst nehmen, bevor man versucht, daran zu kratzen. Eine Komponente, deren Quellen öffentlich und deren Abhängigkeiten deklariert sind, startet von einer besseren Position als ein proprietärer Tech-Stack, in den man nicht hineinschauen kann. Es ist die These, die SUSE im Kommentar zur Verordnung präzise formuliert hat: Die offene Infrastruktur, in der jede Komponente prüfbar und jede Abhängigkeit deklariert ist, erfüllt jene Transparenzanforderung auf eine Weise, die geschlossene Software nicht erreicht. Das stimmt. Die Orchid-Kampagne widerlegt diese These nicht, sie verschiebt sie um einen Schritt, auf ein Terrain, das die These nicht abdeckte. Offen heißt prüfbar im Prinzip. Es heißt nicht geprüft. Und im Maßstab von Hunderten Millionen Repositories ist das Prinzip genau der Ort, an dem die Angriffe nisten. Vertrauen ist in der Softwareentwicklung eine Ökonomie wie jede andere, und wie jede andere versucht es zu sparen. Den Code jeder Abhängigkeit, die wir importieren, wirklich zu lesen, würde mehr kosten als die Zeit, die wir haben, und so tun wir es fast nie. Wir lesen die Signale, die ihn umgeben: die Anzahl der Sterne, die Historie, die Autoren, die Position in den Suchergebnissen. Diese Signale sind eine Vollmacht, eine Delegation, die wir in drei Sekunden unterschreiben, jedes Mal, wenn wir etwas klonen. Die Angreifer von Orchid haben nicht unsere Fähigkeit verletzt, den Code zu lesen. Sie haben gelernt, die Münze zu prägen, mit der wir das Vertrauen bezahlen, um ihn nicht lesen zu müssen. Die Fälschung betrifft nicht die Quelle, sie betrifft den Apparat, der uns davon entbindet, sie anzusehen.

Die SBOM wird Gesetz

Hier hört der Diskurs auf, philosophisch zu sein, und wird zu einer Frist im Kalender. Das Werkzeug, das die von der Verordnung versprochene Transparenz in etwas Operatives verwandelt, existiert, hat einen wenig eleganten Namen und eine mittlerweile präzise Rechtsgrundlage. Es ist die Stückliste der Software, die SBOM, und mit dem Cyber Resilience Act wird sie zum ersten Mal eine gesetzliche Pflicht und nicht länger eine gute Praxis. Die Daten liegen nah beieinander. Ab dem 11. September 2026 muss, wer ein Produkt mit digitalen Elementen auf den europäischen Markt bringt, die aktiv ausgenutzten Schwachstellen binnen vierundzwanzig Stunden melden. Ab dem 11. Dezember 2027 muss er in der technischen Dokumentation eine SBOM in maschinenlesbarem Format aufbewahren, die mindestens die Abhängigkeiten der ersten Stufe abdeckt und über den gesamten Unterstützungszeitraum des Produkts aktuell bleibt. Die Bußgelder sind nach dem Modell der DSGVO bemessen, bis zu fünfzehn Millionen Euro oder zweieinhalb Prozent des weltweiten Umsatzes. Und es gibt ein Detail, das viele erst während der ersten Bewertung entdecken: Man kann nicht melden, von dessen Existenz man nichts weiß. Die Frist im September 2026 zu den Schwachstellen macht die SBOM schon jetzt zu einer praktischen Voraussetzung, lange bevor sie förmlich verpflichtend wird, denn ohne ein genaues Inventar der Abhängigkeiten ist das Vierundzwanzig-Stunden-Fenster unmöglich einzuhalten.

Seit Langem arbeite ich an Werkzeugen dieser Art für Kunden in regulierten Sektoren wie Gesundheit und öffentlicher Verwaltung, und das Missverständnis, dem ich am häufigsten begegne, ist, dass die SBOM das abzuliefernde Produkt sei. Ist sie nicht. Die SBOM ist die Frage. Und hier sollte man gleich ein Zugeständnis an die machen, die sich in der Materie auskennen, denn der Einwand ist begründet und muss entschärft werden, bevor er erhoben wird. Eine Stückliste, genommen für das, was die meisten Organisationen daraus machen, sieht den Angriff von Orchid nicht einmal. Jene Repositories schieben keine bösartige Abhängigkeit in dein Manifest, sie überzeugen dich, ein Projekt zu klonen und auszuführen, das sich als ein anderes verkleidet. Ein Scanner, der deinen Abhängigkeitsbaum mit einer Datenbank bekannter Schwachstellen abgleicht, geht hindurch, ohne etwas zu bemerken, denn der Betrug wohnt nicht in der Liste, er wohnt im Ursprung dessen, was die Liste aufzählt. Und genau das ist der Punkt. Die nutzlose Version der SBOM, die fast überall zuerst produzierte, ist ein Standbild: eine statische Liste von Komponenten, vielleicht ein PDF, am Abend vor dem Audit erzeugt und nie wieder angefasst, die sagt, was du hineingelegt hast, und schweigt darüber, woher es kommt und ob es wirklich das ist, was es zu sein vorgibt. Die zehntausend Repositories der Kampagne würden eine solche Prüfung ohne mit der Wimper zu zucken bestehen. Die Frage, die zählt, ist nicht, welche Komponenten da sind, sondern ob jede von ihnen wirklich von dort kommt, woher sie zu kommen behauptet, und auf diese Frage antwortet kein Dokument, sondern eine Verifizierung, ausgeführt in dem genauen Moment, in dem die Komponente in den Build eintritt.

Wer die Erklärung signiert

Und hier reicht die SBOM allein nicht aus, denn eine SBOM ist eine Erklärung, und eine Erklärung lässt sich mit derselben Leichtigkeit fälschen, mit der man eine Commit-Historie fälscht. Die eigentliche Frage tritt einen Schritt zurück: Wer signiert jene Erklärung, und wie schwer ist es für einen Angreifer, eine falsche zu signieren. Die Antwort führt, für jene, die in der Sicherheit der Lieferkette arbeiten, über eine Werkzeugschicht, die in den letzten Jahren stark gereift ist. Das Referenzmodell heißt SLSA und definiert nach Stufen, wie verlässlich die Geschichte ist, wie ein Artefakt gebaut wurde. Diese Geschichte wird in einem signierten Attestierungsformat namens in-toto ausgedrückt, und wirklich signiert dank Sigstore, das die Last langlebiger Schlüssel vermeidet, indem es jede Signatur an eine im Moment verifizierte Identität bindet und ihre Spur in einem öffentlichen und unveränderlichen Register festhält. Der entscheidende Punkt dieses Aufbaus ist nicht die Kryptografie an sich, es ist, wer den Stift in der Hand hält. Selbstzertifizierung ist nichts wert: Wenn dasselbe Build-Skript den Beweis seiner eigenen Ehrlichkeit erzeugt, kann ein Angreifer, der das Skript kontrolliert, den Beweis sagen lassen, was er will. Man hat es vor wenigen Monaten bei einem Angriff auf die Paketkette gesehen, der kryptografisch gültige Herkunftsattestierungen mit sich führte, erzeugt jedoch von einer Build-Plattform, die nicht die von den höheren SLSA-Stufen geforderte Isolation gewährleistete. Herkunft wird erst dann glaubwürdig, wenn sie von einer isolierten Umgebung erzeugt wird, von der Plattform und nicht vom Nutzer kontrolliert, sodass nicht einmal der lügen kann, der Zugriff auf die Konfiguration hat. Nicht zufällig wurden die reproduzierbaren Builds, also die Fähigkeit, bitgenau dasselbe Artefakt aus denselben Quellen zu rekonstruieren, aus den jüngsten Versionen von SLSA gestrichen: Sie waren das theoretische Ideal und erwiesen sich in der Praxis als zu schwer zu erreichen. Auch die Verifizierung hat, kurz gesagt, ihren Regress. Jemand muss den Zertifizierer zertifizieren, und die einzige solide Antwort ist, jenen jemand außer Reichweite derer zu verlagern, die ein Interesse am Schummeln hätten.

Und hier kehrt die Ironie, die der faule Leitartikler erahnt hatte, zurück, doch weit schärfer, als er sie zurückgelassen hatte. Die Attestierungsschicht, die ich gerade beschrieben habe, ist reif. GitHub selbst bietet nativ die Erzeugung signierter Herkunftsbeweise für die Artefakte an, die aus seinen Pipelines herauskommen, und ein anständiges Garantieniveau zu erreichen ist heute eine Sache eines Arbeitsnachmittags, nicht mehr eines wochenlangen Projekts. Die Plattform liefert also das kryptografische Schloss für das Paket, das du produzierst, und lässt zur gleichen Zeit absichtlich zu, dass das Schild mit dem Namen an der Tür des Repositories gefälscht werden kann, aus dem jenes Paket zu stammen scheint. Sie stellt die Werkzeuge bereit, um zu beweisen, dass ein Artefakt aus einem bestimmten Build stammt, und weigert sich, das Vortäuschen zu erschweren, dass ein ganzes Projekt von einem bestimmten Autor stammt. Die beiden Dinge wohnen unter derselben Adresse und reden nicht miteinander.

Wo die Souveränität wohnt

Kehren wir also zu der Frage zurück, von der wir ausgegangen sind, wo die Souveränität wohnt. Nicht im Rechenzentrum, das der leicht zu legiferierende und leicht zu messende Teil ist, und genau deshalb reden alle darüber. Die Geografie der Bytes ist auf dem Papier in dem Moment ein gelöstes Problem, in dem du sie in ein Leistungsverzeichnis schreibst. Die Herkunft der Komponenten, die in jenem Rechenzentrum laufen, ist ein Problem, das bei jedem Build aufs Neue bewiesen werden muss, bei jeder Abhängigkeit, gegen einen Gegner, der jedes Interesse daran hat, vorschriftsmäßig zu erscheinen. Europa hat, vielleicht ohne es bis zum Ende auszusprechen, die Herkunft zur tragenden Wand des ganzen Gebäudes gemacht. Doch die Sprache der Verordnung benennt das Ergebnis und schweigt über den Mechanismus. Sie fordert Transparenz über die Lieferkette und sagt nicht, signiert von wem, noch geprüft gegen welches Kriterium im Moment der Freigabe in Produktion. Der Abstand zwischen eine SBOM zu haben und beweisen zu können, dass die SBOM die Wahrheit sagt, ist die ganze Partie, und es ist genau der Abstand, den dieselben fünfzehn Junitage offen zutage gelegt haben. Auf der einen Seite eine Verordnung, die auf die überprüfbare Lieferkette wettet, auf der anderen ein einzelner Forscher, der mit einem Skript beweist, dass die Lieferkette heute nicht in der Lage ist, sich selbst zu attestieren.

Es bleibt das Unbequeme zu sagen. Open Source first ist das richtige Prinzip und ein leeres Prinzip, solange offen nicht mit attestiert gekoppelt wird. Die Transparenz der Quellen ist eine notwendige Bedingung der Souveränität und in keiner Weise hinreichend, denn zwischen dem Hinschauenkönnen und dem Hingeschauthaben öffnet sich der Raum, in dem ein Gegner zehntausend Repositories baut, auf die niemand schaut. Souveränität ist kein Ort, den man erreicht, sie ist eine Eigenschaft, die man fortwährend beweisen muss, und sie hört in dem genauen Augenblick auf zu existieren, in dem man aufhört, sie zu verifizieren. Die SBOM ist kein Compliance-Möbel, das man für den Auditor in einer Ecke aufbewahrt, sie ist der Punkt, an dem das Wort Souveränität den Boden berührt, vorausgesetzt, darunter liegt eine Attestierungskette, die sie trägt.

Dass GitHub die Korrektur, die das Fälschen der Herkunft erschwert hätte, Funktion genannt hat, ist das aufschlussreichste Detail der ganzen Geschichte. Die Plattform hat entschieden, dass sie die Verifizierungsschicht nicht baut. Was bedeutet, dass jene Schicht für jeden, der die Sprache der europäischen Verordnung ernst nimmt, zur Arbeit wird, die woanders zu leisten ist, in den Pipelines und Praktiken derer, die Software für die Sektoren liefern, die das Gesetz gleich enger zieht. Die europäische Wette auf die Souveränität der Lieferkette ist im Grunde die Wette, dass jemand die Attestierungsschicht baut, die die Plattform zu bauen sich weigert. Jene Schicht ist die eigentliche Arbeit. Alles Übrige sind Megawatt.

Der Autor

Andrea MargiovanniEU-Compliance

Ich arbeite mit Teams, die Systeme unter AI Act, CRA, NIS2, DSGVO bauen. Die Regel ist keine Checkliste: sie ist eine architektonische Einschränkung, die schon beim Entwurf an Bord muss, nicht danach.

Zum Weg →