Container-Technologie im Unternehmen: Standardisierung trifft auf rechtliche Herausforderungen

Container sind aus der modernen Softwareentwicklung nicht mehr wegzudenken. Sie ermöglichen es, Anwendungen mitsamt ihrer Laufzeitumgebung in isolierten, standardisierten Einheiten zu betreiben. Besonders im DevOps-Kontext sowie in Continuous Integration- und Deployment-Prozessen (CI/CD) bieten Container ein hohes Maß an Effizienz und Flexibilität. Doch mit dem Einsatz dieser Technologie ergeben sich auch rechtliche Fragestellungen, die Unternehmen nicht unterschätzen sollten.

Docker als Deonym für Containerarchitektur

Container sind ein Konzept zur Prozessisolation auf Betriebssystemebene und existieren unabhängig von konkreten Implementierungen. Sie nutzen systemeigene Mechanismen, um Anwendungen voneinander zu trennen und gleichzeitig auf einem gemeinsamen Kernel auszuführen. Dieses Prinzip wurde bereits vor Docker in Technologien wie FreeBSD Jails oder Linux VServer umgesetzt.

Docker ist lediglich eine Implementierung dieses Containerprinzips – wenn auch derzeit die bekannteste.
Die gleichnamige Firma Docker Inc. hat mit ihrer Plattform die Nutzung von Containern erheblich vereinfacht, insbesondere durch das Image-Format, das Repository-System (Docker Hub) und das standardisierte Command Line Interface (CLI). Dennoch gibt es zahlreiche Alternativen: Containerd, Podman, CRI-O oder rkt verfolgen ähnliche Ziele, teilweise mit anderen Schwerpunkten – etwa Rootless-Containern, Kubernetes-Kompatibilität oder geringerer Komplexität.

Während „Docker“ oft synonym für  Container verwendet wird, ist es technisch betrachtet daher nur eine konkrete Ausprägung eines weiter gefassten Konzepts.

Das Innenleben: Wie Namespaces, cgroups und Layer Container ermöglichen

Container basieren technisch auf etablierten Linux-Mechanismen wie Namespaces und Control Groups (cgroups), die für Prozessisolation und Ressourcenkontrolle sorgen. Namespaces sorgen dafür, dass ein Container nur seine eigenen Prozesse (PID), sein eigenes Netzwerk (NET),
Dateisysteme (MNT) und weitere Systemressourcen sieht.

Cgroups begrenzen gleichzeitig den Ressourcenverbrauch einzelner Container, etwa in Bezug auf CPU- oder RAM-Nutzung.

Ein wesentliches Merkmal der Containerarchitektur ist das Schichtensystem (Union File System). Container-Images bestehen aus mehreren schreibgeschützten Layern, die durch die Anweisungen im Build-Manifest (Dockerfile) erzeugt werden. Nur die oberste Schicht ist beschreibbar. Mehrere Container können somit dieselben Basis-Images nutzen, ohne Speicher zu duplizieren, was die Effizienz deutlich erhöht. Beim Start eines Containers wird lediglich eine dünne, schreibbare Ebene hinzugefügt.

Diese Architektur ermöglicht sehr kurze Startzeiten, da kein vollständiges Betriebssystem gebootet werden muss. Container sind damit deutlich ressourcenschonender als klassische virtuelle Maschinen. Allerdings bedeutet dies auch, dass alle Container denselben Kernel des Hostsystems nutzen. Ein potenzielles Risiko bei fehlerhaften Konfigurationen oder Kernel-Exploits.

Das Lizenz-Dilemma: Free und Open Source-Compliance in der „Black Box“

Ein Großteil der Container-Images basiert auf FOSS-Komponenten. Dies betrifft nicht nur die Basissysteme wie Alpine oder Ubuntu, sondern auch zahlreiche Bibliotheken und Tools, die im Container mitgeliefert werden. Unternehmen, die eigene Container-Images erstellen oder übernehmen, müssen sicherstellen, dass die enthaltenen Lizenzen eingehalten werden.

Beim Einsatz von Drittcontainern stoßen viele Unternehmen auf ein zentrales Problem: Die gelieferten Container-Images enthalten in der Regel ausschließlich Binärdateien, jedoch keinen separaten, auswertbaren Quellcode. Damit fehlt die notwendige Transparenz für eine fundierte Bewertung der enthaltenen Komponenten, insbesondere im Hinblick auf FOSS-Lizenzkonformität. Zwar existieren Tools zur Analyse, die eine Software Bill of Materials (SBOM) generieren können – etwa mit Formaten wie SPDX oder CycloneDX –, doch bleibt die Auswertung auf Basis von Binaries technisch limitiert und rechtlich unsicher. Der OpenChain Telco SBOM Guide v1.1[1] bietet hierzu einen strukturierten Ansatz, wie Container-SBOMs aufgebaut und mit den notwendigen Informationen versehen werden sollten, um Transparenz über alle enthaltenen Pakete, deren Herkunft, Lizenz und Beziehungen herzustellen.

Ein valides Compliance-Management für Container muss vorsehen, dass alle Bestandteile eines verwendeten Docker-Images identifiziert, dokumentiert und einzeln auf Lizenzvereinbarkeit geprüft werden. In der Praxis scheitert dies häufig bereits an der Ermittelbarkeit grundlegender Informationen. Bei vielen öffentlich verfügbaren Container-Images fehlen zentrale Lizenzangaben, etwa die Angabe der „declared license“ im SPDX-Sinn, die Angabe des Lizenztextes selbst oder der Quellcodeverweis (Download Location). Ohne diese Informationen ist eine rechtssichere Bewertung kaum möglich. Insbesondere, wenn unterschiedliche Lizenztypen kombiniert vorliegen, etwa eine permissive Lizenz (z. B. Apache-2.0) zusammen mit Copyleft-basierten Komponenten (z. B. GPL-2.0 bei Linux Systemen). Solche Kombinationen können je nach Einbindungsform zu Lizenzinkompatibilitäten führen und bergen erhebliche Risiken.

Darüber hinaus ist oft unklar, ob bestimmte rechtliche Anforderungen eingehalten wurden, etwa im Hinblick auf die sogenannte „Tivoisierung“, der Verpflichtung bestimmter Lizenzen (z. B. der GPL-3.0), neben dem Quellcode auch die Installationsmechanismen (wie etwa Signaturschlüssel) zur Verfügung zu stellen, wenn das Programm auf Hardware ausgeführt wird, die deren Austausch verhindern soll. Gerade bei vorgefertigten Binärcontainern fehlt in der Regel jegliche Dokumentation dazu, ob solche Pflichten beachtet wurden oder ob ein den Lizenzen entsprechender Austauschmechanismus etabliert werden kann. Die Komplexität steigt mit jeder zusätzlichen Schicht (Layer), da Container-Images häufig auf anderen Images basieren, die wiederum weitere Abhängigkeiten mit sich bringen. Diese verschachtelten Strukturen erschweren die Rückverfolgung von Lizenzhinweisen erheblich.

Ein umfassendes Compliance-Management muss also nicht nur auf Werkzeuge zur SBOM-Erstellung setzen, sondern auch auf ein tiefes Verständnis der Lizenzlandschaft sowie auf klare Prozesse zur Validierung und Dokumentation aller relevanten Lizenzinformationen. Diese Tiefenanalyse ist jedoch nur zuverlässig möglich, wenn entweder eine vollständige und konforme SBOM vorliegt oder das Image aus eigener Hand gebaut wurde. Eigene Dockerfiles bieten hier entscheidende Vorteile: Sie erlauben vollständige Kontrolle über die verwendeten Basisschichten, Abhängigkeiten und Build-Prozesse. So lassen sich gezielt nur solche Komponenten einbinden, deren Lizenzen bekannt und rechtlich handhabbar sind. Zudem lassen sich dadurch Sicherheit und Wartbarkeit erhöhen, etwa durch den Ausschluss veralteter Pakete oder durch reproduzierbare Builds.

Datenschutzfalle: Warum technische Isolation nicht vor der DSGVO schützt

Container schaffen technische Isolation, keine rechtliche. Zwar sind Containerprozesse voneinander abgeschirmt – etwa durch cgroups und Namespaces – doch können innerhalb eines Containers dennoch personenbezogene Daten verarbeitet oder sicherheitsrelevante Dienste betrieben werden. Sobald ein Container personenbezogene Daten im Rahmen einer Niederlassung in Europa verarbeitet oder (ohne Niederlassung) speziell für das Anbieten von Waren/Dienstleistungen an oder die Beobachtung des Verhaltens von Personen in der Union verarbeitet, greifen die Bestimmungen der DSGVO. Das gilt auch dann, wenn der Container im Unternehmen lediglich zu Testzwecken läuft.

Besondere Aufmerksamkeit ist auch dem Logging zu widmen: Wenn mehrere Container eines Microservices-Verbunds zentrale Logsysteme verwenden, müssen Unternehmen sicherstellen, dass keine „unsaubere“ Vermischung von Daten erfolgt, etwa durch unautorisierte Cross-Container-Einsichtnahmen.

Automatisierte Risiken: Wenn CI/CD-Pipelines Daten in Drittstaaten transferieren

Wird ein Container nicht lokal, sondern auf einer Public-Cloud-Plattform betrieben, sind die bekannten datenschutzrechtlichen Herausforderungen bei Drittstaatentransfers zu beachten. Insbesondere US-Anbieter unterliegen dem CLOUD Act, was einen Zugriff auf verarbeitete Daten durch US-Behörden ermöglichen kann. Da Container in CI/CD-Umgebungen oft automatisiert in Cloudumgebungen deployed werden, besteht die Gefahr, dass personenbezogene Daten unbemerkt in unsichere Drittländer abfließen. Ein Vertrag zur Auftragsverarbeitung (Art. 28 DSGVO) sowie geeignete Garantien für Drittlandübermittlungen (Art. 46 DSGVO) sind hier unverzichtbar.

Vertrauensproblem Docker Hub: Supply-Chain-Sicherheit und Haftungsfragen

Container schaffen nicht nur neue Möglichkeiten, sondern auch neue Angriffsflächen. Da Images oft aus öffentlichen Repositories wie Docker Hub stammen, ist eine genaue Analyse der enthaltenen Komponenten erforderlich. Veraltete Pakete, manipulierte Abhängigkeiten oder unsichere Konfigurationen sind keine Seltenheit. Die Verantwortung liegt beim Unternehmen, die verwendeten Images regelmäßig durch automatisierte Scans auf bekannte Schwachstellen zu prüfen (z. B. durch Snyk, Trivy oder Clair).

Hinzu kommt, dass der Einsatz von Third-Party-Images ohne nachvollziehbare Herkunft kann auch haftungsrechtliche Risiken bergen. Kommt es durch eine unsichere Image-Komponente zu einem Schaden, kann sich das Unternehmen möglicherweise nicht auf das Fehlen von Vorsatz oder grober Fahrlässigkeit berufen, wenn grundlegende Sicherheitsprüfungen unterlassen wurden.

Container brauchen Compliance!

Containertechnologie vereinfacht Softwarebetrieb, bringt aber juristische Komplexität mit sich. Wer Container in sensiblen Bereichen einsetzt, sollte technische und rechtliche Prozesse aufeinander abstimmen: durch ein belastbares Lizenzmanagement, Datenschutz-Folgenabschätzungen, Sicherheitsrichtlinien und klare Verantwortlichkeiten. Nur so lässt sich die gewünschte Agilität mit der notwendigen Rechtssicherheit verbinden.