KW 17/2026: Cloud-Souveränität trifft Supply-Chain-Risiken

Wenn ich diese Woche auf die Security-News schaue, sehe ich drei Entwicklungen, die auf den ersten Blick unterschiedlich wirken – auf den zweiten aber das gleiche Problem offenlegen: Abhängigkeiten. Abhängigkeiten von Cloud-Anbietern, von KI-Diensten und von Entwicklerpaketen. Das BSI legt mit seinen neuen C3A-Kriterien den Finger in die Wunde der Cloud-Souveränität, GitHub verändert die Kostenstruktur von Copilot – und ein kompromittiertes PyPI-Paket zeigt erneut, wie fragil Software-Lieferketten geworden sind. Für Unternehmen, vor allem hier in Aachen und NRW, ergibt sich daraus eine klare Botschaft: wer Kontrolle behalten will, muss wissen, worauf er sich einlässt.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die sogenannten C3A-Kriterien – „Criteria enabling Cloud Computing Autonomy“ – veröffentlicht. Der Name klingt sperrig, aber der Hintergrund ist klar: Deutschland und Europa sollen bei Cloud-Diensten unabhängiger von ausländischen Anbietern werden. Laut BSI geht es dabei um zentrale Punkte wie Datenspeicherung, Betreibertransparenz, Kontrolle über die Software-Stacks und Transparenz in der Lieferkette. Also genau die Aspekte, die Unternehmen seit Jahren in ihren Compliance-Audits hinterfragen, aber selten klar bewertet bekommen.

Ehrlich gesagt überrascht es mich, dass so ein Rahmenwerk erst jetzt kommt. Die Diskussion um Cloud-Souveränität läuft seit mindestens zehn Jahren. Aber die Umsetzung war bisher diffus: Jeder Cloud-Provider wirbt mit Sicherheit und Kontrolle, aber kaum jemand konnte nachvollziehbar darlegen, ob das wirklich stimmt. Mit den C3A-Kriterien schafft das BSI nun ein strukturiertes Bewertungsraster, das öffentliche Auftraggeber künftig als Maßstab für Beschaffung und Zertifizierung nutzen dürften. Für Unternehmen in Aachen, die im Automotive- oder Maschinenbau-Bereich tätig sind, wird das spannend – denn Cloud-Compliance ist mittlerweile Teil vieler Lieferkettenaudits.

Aus meiner Sicht ist das C3A-Rahmenwerk mehr als nur ein technisches Papier. Es geht um digitale Selbstbestimmung, nicht nur um Datenspeicherung. Denn wenn man die Hoheit über Betrieb und Update-Kette einer Cloud verliert, verliert man letztlich auch Kontrolle über Sicherheit. Die Kriterien adressieren genau das – von Schlüsselmanagement über Software-Lieferwege bis hin zu Exit-Szenarien. Und mal ehrlich: Solche Vorgaben hätte man auch aus eigenem betrieblichem Interesse schon längst gebraucht.

Während das BSI also auf Kontrolle pocht, öffnet GitHub (und damit indirekt Microsoft) die nächste Stufe der Cloud-Ökonomie: Copilot wird ab Juni nutzungsbasiert abgerechnet. Bisher war das ein Abo-Modell, jetzt kommt Pay-as-you-go – also Bezahlung pro verwendeter Anfrage oder Output. Klingt harmlos, kann aber für Unternehmen mit vielen Entwicklern schnell spürbar werden. Laut ComputerBase betrifft das nicht nur die Buchhaltung, sondern auch die Art, wie man KI-gestützte Entwicklungsprozesse plant. Denn wer nach Verbrauch zahlt, muss wissen, wie viele Copilot-Vorschläge in einer CI/CD-Pipeline tatsächlich produktiv genutzt werden.

Technisch bleibt Copilot natürlich beeindruckend, aber organisatorisch ist das eine Herausforderung. Wenn Entwickler unbewusst jede Codezeile mit Copilot-Vorschlägen befüllen, kann das unbeabsichtigt zusätzliche Kosten erzeugen. Noch schwieriger wird es, wenn automatisierte Prozesse wie Code-Generierung in Build-Systemen eingebunden sind – dann hat man plötzlich Machine-Learning-Kosten im Entwicklertakt. Und das alles zentralisiert bei einem Anbieter, der die Regeln diktiert. Aus meiner Sicht ist das eine Art Rückschritt in Richtung Vendor-Lock-in – diesmal nicht technisch, sondern wirtschaftlich.

Für IT-Abteilungen in NRW, die ohnehin unter Budgetdruck stehen, bedeutet das: Sie brauchen nicht nur Security Governance, sondern auch Kosten-Governance. Ein KI-Service, der bei jedem Commit Geld kostet, wirkt plötzlich nicht mehr so produktiv, wenn die Monatsabrechnung ins Haus flattert. Die Frage ist also: Wie souverän ist ein Unternehmen noch, wenn die Kern-Tools seiner Entwickler faktisch dynamisch bepreist werden? Die Antwort finden wir vermutlich bald – wenn die ersten Rechnungen eintreffen.

Und dann war da noch das, was ich als klassisches Déjà-vu der Entwickler-Security bezeichnen würde: Ein populäres Paket aus der Python Package Index (PyPI) wurde kompromittiert und infektiös mit einem Infostealer verbreitet – bei etwa 1,1 Millionen monatlichen Downloads. Laut BleepingComputer betraf das ein Paket, das in zahlreichen Projekten und Build-Pipelines automatisch eingebunden ist. Das heißt im Klartext: Ein Entwickler muss gar nichts bewusst installieren – allein der CI/CD-Prozess reicht, um Schadcode in Produktionssysteme einzuschleusen.

Das macht die Sache so gefährlich. Supply-Chain-Angriffe sind technisch gesehen Raffinessen mit massiven Folgen. Hier greifen Angreifer nicht den Server oder Nutzer direkt an, sondern sie platzieren ihren Code dort, wo alle vertrauen: in Bibliotheken und Open-Source-Dependencies. Wenn man dann noch sieht, dass viele Organisationen ihre Artefakte nicht signieren oder auf bekannte Repositories fixieren, wundert es nicht, dass die Attacken erfolgreich sind. Was mich immer wieder irritiert: Wir wissen das seit Jahren. Aber Dependency-Management ist unbequem – und wird daher oft aufgeschoben.

Die Ironie der Woche: Während das BSI über souveräne Cloud-Lieferketten nachdenkt, zeigen solche PyPI-Vorfälle genau, wie unsouverän viele Entwicklerumgebungen aktuell sind. Wer bei jedem Build automatisiert fremden Code aus dem Internet zieht, hat faktisch keine Kontrolle mehr über seine Software-Lieferkette. Und das betrifft nicht nur Start-ups – auch größte Unternehmensnetzwerke in der Städteregion Aachen hängen davon ab. Ein einziger infizierter Package-Import kann reichen, um interne Systeme zu kompromittieren.

Die drei Themen weisen in unterschiedliche Richtungen, aber sie münden in derselben Erkenntnis: Transparenz und Kontrolle sind die neuen Währungen der IT-Sicherheit. Ob Cloud, KI oder Code-Pakete – immer geht es darum, wer die Fäden in der Hand hat. Für Unternehmen in NRW und besonders hier in Aachen zeigt sich damit eine klare Priorität. Erstens: Prüfen Sie beim Cloud-Einsatz, ob Ihr Anbieter die C3A-Vorgaben erfüllt oder erfüllen kann. Nicht, weil es Gesetz wäre, sondern weil es Ihnen unabhängiger macht. Cloud-Souveränität ist eine Zukunftsfähigkeit, keine Bürokratie.

Zweitens sollten Entwicklungsleiter ihre Nutzung von GitHub Copilot analysieren. Wer den Service produktiv einsetzt, braucht Nutzungsstatistiken – nicht um zu sparen, sondern um Überraschungen zu vermeiden. Und ja, vielleicht braucht es wieder interne Richtlinien, welche Art von Code mit KI-Unterstützung generiert werden darf – nicht alles sollte blind in sicherheitskritische Module übernommen werden.

Drittens: Wenn Sie noch keine Artifact-Repositories mit Signaturvalidierung und Dependency-Scanning nutzen, ist jetzt der Zeitpunkt. Supply-Chain-Security ist kein Luxus, sie ist heute Basisschutz. Dafür gibt es Werkzeuge, meist schon in CI/CD-Systemen integriert. Sie müssen nur eingeschaltet werden.

Diese Woche zeigt auf bedrückende Weise, dass Technik-Abhängigkeit und Sicherheitsverantwortung untrennbar miteinander verbunden sind. Das BSI will mehr Eigenständigkeit in der Cloud, GitHub demonstriert wirtschaftliche Abhängigkeiten, und PyPI beweist, wie gefährlich blindes Vertrauen in offene Lieferketten sein kann. Aus meiner Sicht sind das keine getrennten Themen – es ist ein Spiegelbild der digitalen Realität: Zentralisierte Dienste werden bequemer, aber auch riskanter.

Die gute Nachricht: Wir müssen das nicht hinnehmen. Security, Kostenkontrolle und Souveränität schließen sich nicht aus – sie erfordern nur Planung, klare Richtlinien und technische Disziplin. Patchen, prüfen, verstehen – das klingt altmodisch, aber es schützt mehr als jede KI-basierte Wunderwaffe.

Falls Sie sich fragen, wie Sie Cloud-Compliance, Copilot-Governance oder Supply-Chain-Security in Ihrer Umgebung kombinieren können: Sprechen Sie mich an. Ein pragmatischer Security-Check bringt meist mehr Klarheit als endlose Produktdiskussionen. Und ehrlich gesagt: Kontrolle über die eigene Infrastruktur ist immer die lohnendste Investition.