ITAR-Freiheit in der Werkzeugkette

Problem

Europäische Verteidigungs-, Satelliten-, Marine- und Luftfahrt-Zulieferer haben dieselbe wiederkehrende Audit-Frage: ist sichergestellt, dass keine ITAR-kontrollierten US-Komponenten in der eigenen Werkzeugkette (der Gesamtheit der Software-Dienste, mit denen ein Team entwickelt und arbeitet) stecken? ITAR (International Traffic in Arms Regulations, das US-Exportkontrollrecht für Rüstungsgüter) zieht weite Kreise: Sobald auch nur ein einziges US-Origin-Item der United States Munitions List (USML, die US-Liste kontrollierter Rüstungsgüter) im System auftaucht, ist die Gesamtanlage juristisch betroffen. Anders als bei dual-use-Gütern (Waren mit ziviler und militärischer Verwendbarkeit) gibt es bei ITAR praktisch kein de-minimis (keine Bagatellgrenze): 0,1 Prozent USML-Anteil reichen, um die ganze Lieferkette in das US-Re-Export-Regime hineinzuziehen.

Für wen ist das? Für Unternehmen mit Exportkontroll- oder Souveränitäts-Anforderungen an ihre Werkzeuge.

Kurze Antwort

Dernium ist ausdrücklich kein Compliance-Produkt für Waffensysteme, und wir behaupten das auch nicht. Worum es geht:

• Strukturelle Provenance statt Standort-Versprechen: Dernium baut und betreibt die Werkzeugkette so, dass sie keine ITAR-kontrollierten US-Komponenten in Ihre Umgebung zieht.
• Konkret heißt das: Server in Deutschland, eigener Auth-Stack (Anmelde- und Identitätsverwaltung), kein US-Hyperscaler im Datenpfad, kein US-Identity-Provider, kein US-CDN (Content Delivery Network, ein Auslieferungsnetz für Web-Inhalte).
• Die Grundregel: Was wir nicht hereinziehen, müssen Sie auch nicht reexportieren.
• Die Grenze: ITAR-Konformität bleibt Ihre Compliance-Aufgabe; wir liefern nur eine Werkzeugkette ohne US-USML-Anker.

ITAR und EAR auseinanderhalten

ITAR (22 CFR 120 bis 130) regelt "defense articles" und "defense services" (Rüstungsgüter und zugehörige Dienstleistungen) auf der USML, administriert vom DDTC (Directorate of Defense Trade Controls) im US-State-Department. EAR (Export Administration Regulations; 15 CFR 730 bis 774) regelt dual-use-Güter und einige militärische Items unter dem BIS (Bureau of Industry and Security) im US-Commerce-Department, klassifiziert nach ECCN-Nummern (Export Control Classification Number, der EAR-Warennummer).

Der wichtige Unterschied für die Werkzeugkette: EAR kennt eine de-minimis-Regel (25 Prozent für die meisten Ziele, 10 Prozent für einige). ITAR kennt sie nicht. Wer einen ITAR-freien Stack will, will nicht "wenig" USML-Anteil, sondern keinen.

Deemed-export und Re-Export

ITAR betrachtet die Weitergabe technischer Information an "foreign persons" (Personen ohne US-Staatsangehörigkeit oder dauerhaften US-Aufenthaltsstatus) als Export, auch wenn die Person physisch in den USA sitzt (deemed export, ein "fingierter" Export; 22 CFR 120.50). Ein deutscher Mitarbeiter im US-Tochterunternehmen mit Zugriff auf ITAR-kontrollierte Repositories (Code-Ablagen) ist damit ein genehmigungspflichtiger Vorgang. Re-Export, also die Weitergabe einer ITAR-Komponente vom Empfänger an Dritte, bleibt ohne separate Lizenz verboten.

Praktische Folge: ITAR-Material darf nicht in einer Werkzeugkette landen, in der man die Empfängergruppe nicht vollständig kontrolliert. Ein US-gehostetes SaaS (Software as a Service, im Web betriebene Mietsoftware) für Code, Tickets, Dateien, Identitäten ist genau so eine Werkzeugkette.

Werkzeugkette ist Lieferkette

Eine Standard-Entwicklerwerkzeugkette zieht typischerweise sieben Schichten herein: Cloud-Hosting, Identity-Provider (Anmeldedienst), Code-Hosting, Issue-Tracker (Aufgabenverwaltung), Office- und Wissens-Tools, CI/CD-Runner (automatisierte Bau- und Auslieferungssysteme), Monitoring und Logs, dazu CDN und E-Mail-Versand. Jede dieser Schichten kann ITAR-Material aufnehmen. Sind US-Anbieter darunter, sind US-Personenkreise und US-Recht im Spiel. Das ist nicht automatisch ein Verstoß, aber es ist die Stelle, an der ein Defense-Compliance-Officer (der für Rüstungs-Exportkontrolle zuständige Beauftragte) womöglich "Stop" sagt, weil nicht mehr beweisbar ist, dass nur freigegebene Personen zugegriffen haben.

Provenance, nicht "EU-Region"

Eine "EU-Region" auf einem US-Hyperscaler ist juristisch keine Garantie gegen US-Zugriff. Der CLOUD Act (US-Gesetz, das US-Anbieter zur Datenherausgabe verpflichtet) zwingt US-Anbieter, Daten herauszugeben, unabhängig vom Speicherort. Die Datenschutzkonferenz (das Gremium der deutschen Datenschutzaufsichtsbehörden) hat diese Spannung bereits 2022 ausdrücklich festgehalten im Kontext der DSGVO; für ITAR gilt dieselbe Mechanik, mit größerem Hebel, weil Defense-Daten regelhaft sensibler sind als Kundendaten. Die Frage ist nicht, wo ein Bit liegt, sondern wer rechtlich darauf zugreifen darf.

ITAR-Provenance (nachweisbare, US-freie Herkunft der gesamten Kette) heißt: kein US-Anbieter im operativen Pfad, kein US-USML-Item in der Software-Bill-of-Materials (SBOM, der Software-Stückliste), keine Verarbeitung in US-Jurisdiktion.

Abgelehnte Alternativen

US-Hyperscaler mit "EU sovereign cloud". Verschoben, aber nicht beseitigt: Code, Schlüssel-Custody (Verwahrung der kryptografischen Schlüssel) und Support-Personal liegen weiter in einer US-Konzern-Struktur, die dem CLOUD Act unterliegt. Für DSGVO ist das diskutabel, für ITAR-Provenance unzureichend, weil die Frage ist, ob US-Personen Zugriff haben könnten, nicht wo das Rechenzentrum tatsächlich steht.

GitHub-Mirror auf EU-Servern. Ein Mirror (eine gespiegelte Zweitkopie) verändert die Provenance nicht. Das primäre Repository samt Identitäten, CI-Logs, Issue-Tracker bleibt bei GitHub Inc., und der Compliance-Officer fragt nach dem Primär-System.

Tagging einzelner Repos als "USML, Zugriff beschränkt". Schwer durchhaltbar bei wachsenden Teams; Tagging-Disziplin (das konsequente Kennzeichnen) ist ein bekannter Schwachpunkt jedes ITAR-Audits. Strukturelle Trennung schlägt prozedurale.

Was Sie jetzt tun sollten

1. Werkzeugkette inventarisieren: Listen Sie für die sieben Schichten (Hosting, Identität, Code, Tickets, Office, CI/CD, Monitoring) den jeweiligen Anbieter und dessen Konzernsitz auf.
2. US-Anbieter im Datenpfad markieren: Kennzeichnen Sie jede Schicht, in der ein US-Anbieter oder eine US-Tochter ITAR-Material aufnehmen könnte - das sind die Stellen, an denen ein Audit ansetzt.
3. Empfängerkontrolle prüfen: Klären Sie für jede Schicht, ob Sie nachweisen können, dass ausschließlich freigegebene Personen Zugriff haben. Wo das nicht beweisbar ist, gehört kein ITAR-Material hinein.
4. Strukturelle Trennung statt Tagging anstreben: Verlagern Sie kontrolliertes Material in eine Kette ohne US-Anbieter, statt einzelne Ablagen nur zu kennzeichnen - Tagging-Disziplin hält im Audit selten stand.
5. Provenance dokumentieren: Halten Sie für besonders strenge Prüfungen fest, woher Ihre Bausteine stammen (etwa über Reproducible Builds, nachvollziehbar reproduzierbare Bau-Ergebnisse), damit Sie die Herkunft belegen können.

Wie Dernium hier hilft

Dernium ersetzt nicht den Compliance-Apparat, den ein Defense-Auftragnehmer ohnehin braucht. Dernium ist die Werkzeugkette daneben, die ihrerseits keine ITAR-kontrollierte US-Substanz hereinzieht.

Dernium Office basiert auf CryptPad und ONLYOFFICE als Container auf deutschen Servern, ohne US-Cloud oder Firmenbeteiligung. Dernium Note, Dernium Send und Dernium Clean laufen auf demselben EU-Stack, ohne CDN bei Cloudflare oder AWS und ohne US-Telemetrie. Dernium Stift ist als OSS-Projekt (Open-Source-Software, quelloffen) verfügbar, sodass Sie die Lieferkette selbst nachvollziehen können.

Was wir nicht versprechen: dass Sie damit "ITAR-konform" sind. ITAR-Konformität ist Ihre Compliance-Aufgabe, nicht unsere. Was wir versprechen: dass die Werkzeugkette, in der Sie alltäglich mit unseren Produkten arbeiten, keinen US-USML-Anker mitbringt, der in einem Audit auf Ihren Tisch fällt.

Offene Punkte

Rust-Toolchain. Der Compiler ist Open Source unter MIT/Apache 2.0, aber die Rust Foundation hat US-Sitz und US-Mitglieder. Die Toolchain-Provenance ist sauber prüfbar (Reproducible Builds), Operatoren mit besonders strenger Prüfung sollten einen eigenen Bootstrap-Build (selbst kontrolliertes Erst-Kompilat) dokumentieren.

ONLYOFFICE-Provenance. Heutige Strukturen in Lettland und Singapur. Wir verfolgen das, für Defense-Anwendungen ist eine Prüfung im Einzelfall sinnvoll.

Linux-Kernel und glibc enthalten Beiträge aus US-Firmen. ITAR betrifft sie nicht, weil keine USML-Items darin stecken. Wer "kein US-Code" als absoluten Anspruch fährt, hat hier eine andere Diskussion zu führen.

Häufige Fragen

Reicht es, einen US-Cloud-Anbieter mit europäischer Region zu nutzen?

Für ITAR-Provenance nicht. Eine EU-Region verschiebt zwar den physischen Speicherort, aber der CLOUD Act verpflichtet den US-Mutterkonzern weiterhin zur Datenherausgabe, und Code, Schlüsselverwahrung sowie Support-Personal bleiben in einer US-Struktur. Für ITAR zählt nicht, wo das Rechenzentrum steht, sondern ob US-Personen rechtlich Zugriff haben könnten. Eine "EU sovereign cloud" eines US-Anbieters löst dieses Problem nicht vollständig.

Was bedeutet, dass ITAR kein de-minimis kennt?

De-minimis ist eine Bagatellgrenze: Im dual-use-Recht (EAR) bleibt ein geringer US-Anteil unterhalb von 25 beziehungsweise 10 Prozent außerhalb der US-Kontrolle. ITAR kennt diese Schwelle nicht. Schon ein einziges kontrolliertes US-Item der Munitions List zieht die gesamte Anlage in das US-Re-Export-Regime. Deshalb genügt für einen ITAR-freien Stack nicht "wenig" US-Anteil, sondern es darf gar kein kontrolliertes US-Item enthalten sein.

Macht mich Dernium ITAR-konform?

Nein, und das versprechen wir auch nicht. ITAR-Konformität ist eine Aufgabe Ihres eigenen Compliance-Apparats und umfasst Prozesse, Personenfreigaben und Nachweise, die ein Werkzeug nicht abnehmen kann. Dernium liefert lediglich eine Werkzeugkette, die selbst keine ITAR-kontrollierten US-Komponenten in Ihre Umgebung zieht. Damit fällt eine Quelle möglicher Audit-Findings weg, aber die Verantwortung für die Konformität bleibt bei Ihnen.

Warum ist ein GitHub-Mirror auf EU-Servern keine Lösung?

Weil ein Mirror nur eine Kopie ist und die Herkunft nicht verändert. Das primäre System - mit Identitäten, CI-Logs und Issue-Tracker - bleibt bei einem US-Anbieter, und genau danach fragt ein Compliance-Officer. Maßgeblich ist das Primär-System, in dem das kontrollierte Material tatsächlich entsteht und verwaltet wird, nicht eine nachgelagerte Spiegelung in der EU.

Ist Open-Source-Software automatisch ITAR-frei?

Nicht automatisch, aber sie ist prüfbar. Open Source bedeutet, dass der Quellcode offenliegt und Sie die Herkunft der Bestandteile nachvollziehen können - etwa über Reproducible Builds. Entscheidend ist, ob ein kontrolliertes US-USML-Item enthalten ist; reine US-Beiträge zu zivilem Code (wie im Linux-Kernel) sind kein ITAR-Problem. Für besonders strenge Prüfungen empfiehlt sich dennoch, die Toolchain-Herkunft eigenständig zu dokumentieren.