Funktioniert Maven Central in China? Data Residency, ICP & Grenztransfer-Regeln

Was die offizielle Maven Central-Dokumentation über China sagt

Fakt	Primärquelle
Maven Central ist das öffentliche, von Sonatype betriebene Repository, aus dem Ihr Build Open-Source-Abhängigkeiten auflöst. Sonatypes Produktseite gibt an: „Maven Central, or the Central Repository is the largest public repository of open source Java components and libraries, allowing developers to share and consume Java artifacts in a standardized, reliable, and secure way", und dass „Maven Central Repository is professionally managed by Sonatype". Es ist ein gehosteter, offshore gelegener Dienst — die Residency-Frage betrifft also die privaten Artefakte, die Sie hosten, nicht dieses öffentliche Repo.	Sonatype, „Maven Central Repository"-Produktseite (sonatype.com), abgerufen 2026-10-13
Ein Repository-Manager kann in Ihrer eigenen inländischen Infrastruktur als einzige Quelle der Wahrheit für private Artefakte laufen. Sonatype gibt an, Nexus Repository „is available as a SaaS offering, as a self-hosted version for data centers and cloud deployments, and a fully disconnected version for air-gapped environments", und positioniert es, „Manage every binary and artifact, across every team, from a single, auditable source of truth". Ein selbst-gehosteter Repository-Manager (Nexus oder JFrog Artifactory) hält Ihre privaten Artefakte und Build-Ausgaben resident.	Sonatype, „Sonatype Nexus Repository"-Produktseite (sonatype.com), abgerufen 2026-10-13
Private Artefakte oder Test-Fixtures, die personenbezogene Daten tragen, sind ein grenzüberschreitender Transfer, wenn sie offshore gehostet werden. Im Festland erzeugte personenbezogene Daten an ein privates Registry oder Build-System zu senden, das außerhalb Chinas gehostet ist, löst PIPLs Grenztransfer-Regeln aus (Artikel 38–40): Mitteilung, eine gesonderte Einwilligung und einen Transfermechanismus — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung. Bestätigen Sie den Umfang mit Rechtsbeistand.	Gesetz zum Schutz personenbezogener Daten der VR China, Artikel 38–40 — siehe 21YunBox: Cross-Border Data Transfers, abgerufen 2026-10-13
„Wichtige Daten" und Betreiber kritischer Infrastruktur stehen vor einer inländischen Speicherpflicht. Das Cybersicherheitsgesetz verlangt, dass personenbezogene Daten und wichtige Daten, die im Festland von Betreibern kritischer Informationsinfrastruktur gesammelt und erzeugt werden, innerhalb des Territoriums gespeichert werden, mit einer Sicherheitsbewertung vor jeder Ausfuhr — Artikel 39 (vormals Artikel 37), umnummeriert durch die Novelle von 2025, in Kraft seit 2026-01-01. Bestätigen Sie mit Rechtsbeistand, ob Ihre Artefakte oder Build-Daten in den Anwendungsbereich fallen.	Cybersicherheitsgesetz der VR China, Artikel 39 (vormals Artikel 37; Novelle 2025, in Kraft seit 2026-01-01) — siehe 21YunBox: China Cybersecurity Law, abgerufen 2026-10-13

Quellen vom 21YunBox Compliance-Team am 13. Oktober 2026 geprüft.

Für ein Team, das eine JVM-Anwendung nach Festlandchina ausliefert, stellt Maven Central zuerst die falsche Frage. Ja, Ihr Build löst Abhängigkeiten aus Maven Central auf — dem öffentlichen, von Sonatype betriebenen Repository für Open-Source-Java-Komponenten — und ob dieses öffentliche Repository schnell aus Shanghai auflöst, ist eine Frage von Erreichbarkeit und Spiegelung. Dort liegt die Compliance-Entscheidung nicht. Die Entscheidung liegt eine Schicht tiefer, in Ihren eigenen privaten Artefakten. Die privaten JVM-Artefakte Ihrer Organisation sind proprietärer Code — Geschäftsgeheimnisse — und ein Build backt routinemäßig Zugangsdaten, API-Tokens und Konfigurations-Secrets in sie hinein. Wenn diese privaten Artefakte, und der Build, der sie erzeugt, auf der offshore gelegenen Privat-Registry-Cloud eines Anbieters leben, sitzt Ihr konzentriertes geistiges Eigentum samt eingebetteter Secrets außerhalb des Festlands, und die Abhängigkeits-Lieferkette Ihres China-Builds — welcher Code in Ihr China-Deployment gelangt und mit welcher Herkunft — läuft über die Grenze. Das ist die Hälfte, die eine Prüfung „Erreicht mein Build das Registry?” nie sieht.

Maven Central selbst ist öffentlich und offen, und die Exponierung sind nicht die Open-Source-Pakete, die alle ziehen. Sie liegt darin, wo Ihre privaten Artefakte leben und wie sie in einen China-Build gelangen. Ein Maven- oder Gradle-Build liest seine Abhängigkeiten — öffentliche wie private — aus den Repositories, die Sie konfigurieren; wenn Ihre privaten Artefakte in einem offshore gehosteten Feed sitzen, greift jeder China-Build über die Grenze nach Ihrem eigenen proprietären Code. Der Hebel, den jeder JVM-Betrieb bereits hat, ist ein selbst-gehosteter Repository-Manager — ein Sonatype Nexus Repository oder JFrog Artifactory, das Sie in Ihrer eigenen inländischen Infrastruktur betreiben — der Ihre privaten Artefakte und Build-Ausgaben im Festland hält und die vorgelagerten Open-Source-Komponenten, von denen Sie abhängen, zwischenspeichert, sodass proprietärer Code und eingebettete Secrets resident bleiben und die Lieferkette, die Ihr China-Deployment speist, eine ist, die Sie regieren.

Maven Central in China auf einen Blick

Warum „Erreicht mein Build das Registry?” die falsche Frage ist

Eine Erreichbarkeitsprüfung beantwortet, ob ein Build in China Pakete auflösen kann. Angenommen, er löst perfekt auf — das sagt Ihnen immer noch nichts darüber, wo Ihre privaten Artefakte leben, dass Ihr proprietärer Code und die darin eingebackenen Secrets auf einem offshore gelegenen Registry sitzen, oder welche Herkunft der Code trägt, der in Ihren China-Build gelangt. Das öffentliche Registry näher ans Festland zu spiegeln macht Open-Source-Downloads schneller; es verschiebt Ihre privaten Artefakte nicht ins Inland, und es ändert nichts an der Integritätsgeschichte Ihrer Lieferkette. Die Dinge, die über die Compliance-Frage entscheiden — die Residency von proprietärem Code und eingebetteten Secrets, und die Lieferkette, die Ihr China-Deployment speist — liegen darin, wo das private Registry läuft, nicht in Millisekunden.

Wo diese privaten Artefakte oder Test-Fixtures personenbezogene Daten tragen, ist ihr Offshore-Hosting ein grenzüberschreitender Transfer nach PIPL; wo der Code oder die Daten „wichtige Daten” sind, oder Sie kritische Informationsinfrastruktur betreiben, kommt die Datenlokalisierungsregel des Cybersicherheitsgesetzes (Artikel 39 (vormals Artikel 37)) ins Spiel. Ob und wie diese Pflichten gelten, hängt davon ab, was Ihre Artefakte tatsächlich enthalten — wert, mit Rechtsbeistand zu klären, bevor Sie bauen.

Der rechtskonforme Pfad — kartieren, lokalisieren, ausliefern

Kartieren. Wir inventarisieren, welche Ihrer JVM-Artefakte privat sind — Ihr proprietärer Code —, ob Ihre Builds Zugangsdaten oder Secrets in sie einbetten, wo dieses private Registry oder dieser Feed heute gehostet ist, und wie die Abhängigkeits-Lieferkette Ihres China-Builds tatsächlich aussieht.

Lokalisieren. Wir betreiben den privaten Repository-Manager und Artefakt-Speicher im Inland — selbst-gehostet auf Infrastruktur innerhalb des Festlands —, sodass proprietärer Code und eingebettete Secrets resident bleiben; wir halten die Lieferkette des China-Builds im Inland und minimieren, was die Grenze überquert. Lokalisieren heißt, Ihre eigenen Artefakte im Inland zu regieren, niemals durch Umgehung jeglicher Art.

Ausliefern. 21YunBox stellt die rechtskonforme, inländische Privat-Registry- und Artefakt-Auslieferungsschicht vor — oder an die Stelle von — dem offshore gelegenen Feed, bedient mit dem 21YunBox Optimizer vor dem Stack, den Sie bereits betreiben. Kein Neuaufbau, kein Re-Platforming, keine zweite Codebasis.

Die Regel unter allen dreien: das öffentliche Registry bloß erreichbar oder gespiegelt zu machen ist nicht die Antwort, denn Ihre privaten Artefakte und die darin eingebackenen Secrets sind weiterhin offshore. Das private Registry und die Artefakte im Inland zu halten, ist es.

Dies ist ein Compliance- und Residency-Bild, kein Urteil — was gilt, hängt davon ab, was Ihre privaten Artefakte enthalten und wie Ihr China-Build verdrahtet ist, klären Sie es also mit Rechtsbeistand, bevor Sie bauen. Sagen Sie uns, wie Ihre JVM-Artefakte und Ihre Build-Pipeline aussehen, und wir kartieren, was resident bleiben muss, und stellen das inländische private Registry vor Ihren bestehenden Stack. Melden Sie sich für eine Compliance-Einschätzung und ein Angebot.

Compliance-Einschätzung anfordern →

---

Weiterführend:

• Chinas Gesetz zum Schutz personenbezogener Daten (PIPL)
• Chinas Regeln zum grenzüberschreitenden Datentransfer
• Chinas Cybersicherheitsgesetz — Datenlokalisierung
• Was ist die chinesische ICP-Lizenz, und wie bekommt man sie?

Häufige Fragen

Ist Maven Central in China gesperrt?

Das ist die Erreichbarkeitsfrage, und dort liegt die Compliance-Entscheidung nicht. Maven Central ist Sonatypes öffentliches, offshore gelegenes Repository für Open-Source-Java-Komponenten; ob ein Festland-Build es schnell auflöst, ist eine Leistungs- und Spiegelungs-Angelegenheit, die Sie mit einem inländischen Cache adressieren können, und es gibt nichts zu umgehen — wir nutzen oder empfehlen niemals Umgehung. Die Frage, die Gewicht trägt, sind Ihre privaten Artefakte: proprietärer Code, der Secrets einbetten kann, und wo er gehostet wird. Bestätigen Sie die Einzelheiten mit Rechtsbeistand.

Warum sind unsere privaten Maven-Artefakte ein Data-Residency- und Lieferketten-Problem?

Ihre privaten JVM-Artefakte sind der proprietäre Code Ihrer Organisation — Geschäftsgeheimnisse — und ein Build backt routinemäßig Zugangsdaten, API-Tokens und Konfigurations-Secrets in sie hinein. Auf der offshore gelegenen Privat-Registry-Cloud eines Anbieters gehostet, sitzen dieser konzentrierte Code und seine Secrets außerhalb des Festlands, und die Abhängigkeits-Lieferkette Ihres China-Builds — welcher Code in Ihr China-Deployment gelangt, mit welcher Herkunft — läuft über die Grenze. Wo die Artefakte personenbezogene oder wichtige Daten tragen, können PIPLs Grenztransfer-Regeln (Artikel 38–40) und die Datenlokalisierungsregel des Cybersicherheitsgesetzes (Artikel 39 (vormals Artikel 37)) gelten. Eine Erreichbarkeitsprüfung sieht nichts davon.

Wie halten wir unsere privaten Artefakte und die Build-Lieferkette im Inland?

Betreiben Sie einen selbst-gehosteten Repository-Manager — zum Beispiel Sonatype Nexus Repository oder JFrog Artifactory — in Ihrer eigenen inländischen Infrastruktur, sodass Ihre privaten Artefakte und Build-Ausgaben resident bleiben, während er die vorgelagerten Open-Source-Komponenten, von denen Sie abhängen, zwischenspeichert. 21YunBox kartiert, welche Artefakte und Secrets resident bleiben müssen, stellt die rechtskonforme, inländische Privat-Registry- und Artefakt-Schicht vor (oder an die Stelle von) dem offshore gelegenen Feed und liefert jede China-gerichtete Oberfläche im Inland mit dem 21YunBox Optimizer aus — kein Neuaufbau. Es ist kein inländisches Maven Central, und wir nutzen oder empfehlen niemals Umgehung. Klären Sie den Umfang mit Rechtsbeistand, bevor Sie bauen.