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 stecken? Sobald auch nur ein einziges US-Origin-Item der United States Munitions List im System auftaucht, ist die Gesamtanlage juristisch betroffen. Anders als bei dual-use-Gütern gibt es bei ITAR praktisch kein de-minimis: 0,1 Prozent USML-Anteil reichen, um die ganze Lieferkette in das US-Re-Export-Regime hineinzuziehen.

Kurze Antwort

Dernium ist explizites kein Compliance-Produkt für Waffensysteme, und wir behaupten das auch nicht. Was Dernium tut: die produktivere Werkzeugkette so bauen und betreiben, dass sie keine ITAR-kontrollierten US-Komponenten in Ihre Umgebung zieht. Server in Deutschland, eigener Auth-Stack, kein US-Hyperscaler im Datenpfad, kein US-Identity-Provider, kein US-CDN. Was wir nicht hereinziehen, müssen unsere Kunden auch nicht reexportieren.

ITAR und EAR auseinanderhalten

ITAR (22 CFR 120 bis 130) regelt "defense articles" und "defense services" auf der USML, administriert vom DDTC im US-State-Department. EAR (15 CFR 730 bis 774) regelt dual-use-Güter und einige militärische Items unter dem BIS im US-Commerce-Department, klassifiziert nach ECCN-Nummern.

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" als Export, auch wenn die Person physisch in den USA sitzt (deemed export, 22 CFR 120.50). Ein deutscher Mitarbeiter im US-Tochterunternehmen mit Zugriff auf ITAR-kontrollierte Repositories 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 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, Code-Hosting, Issue-Tracker, Office- und Wissens-Tools, CI/CD-Runner, 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 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 verpflichtet US-Anbieter, Daten herauszugeben, unabhängig vom Speicherort. Die Datenschutzkonferenz 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 heißt: kein US-Anbieter im operativen Pfad, kein US-USML-Item in der Software-Bill-of-Materials, keine Verarbeitung in US-Jurisdiktion.

Abgelehnte Alternativen

US-Hyperscaler mit "EU sovereign cloud". Verschoben, aber nicht beseitigt: Code, Schlüssel-Custody 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. Mirror 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 ist ein bekannter Schwachpunkt jedes ITAR-Audits. Strukturelle Trennung schlägt prozedurale.

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 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 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.