Ein CTO kann Software einkaufen, aber nicht die Verantwortung für ihre Datenwege. Gerade bei geerbten Anwendungen wirken Eigenentwicklung und Kauf zunächst wie eine Budgetentscheidung; später entscheidet sich jedoch, wer einen unerwarteten Datenabfluss nachweisen, stoppen und erklären kann. Meine Position: Kaufen ist oft die bessere Wahl, sofern der Anbieter überprüfbare Kontrolle ermöglicht. Fehlt sie, kann selbst ein teurer Eigenbau wirtschaftlicher sein.
Ein Kaufvertrag ersetzt keine Kontrolle über Datenabflüsse
Die gefährlichste Frage bei „Build or Buy“ lautet nicht, wer die Funktion schneller liefert. Sie lautet: Wer kann nach einer Änderung sagen, welche personenbezogenen Daten an welchen Empfänger gegangen sind? Ein Anbieter kann Sicherheitsupdates zuverlässig ausliefern und zugleich ein neues Diagnose-SDK aktivieren. Das Update schließt dann eine Schwachstelle, während es Gerätekennungen oder Fehlermeldungen an einen weiteren Dienst sendet. Für die Entscheidung zählt deshalb nicht allein die Update-Zusage, sondern auch die Sichtbarkeit der ausgehenden Verbindungen.
Die Analyse JavaFX oder Swing wo Teams spaet Privacy Leaks erben beschreibt das Problem aus Sicht geerbter Desktop-Software; für die Kaufentscheidung greift der Blick auf den Anwendungscode allein zu kurz, weil auch Installer, Crash-Reporter und Update-Dienste Daten übertragen können. Bei einer Java-Anwendung wären etwa JavaFX, Swing und JDK 17 im Bestand zu erfassen. Bei einem gekauften Produkt brauchen Sie stattdessen eine belastbare Komponentenliste, Angaben zu Telemetrie und ein Verfahren, Änderungen daran vor dem Rollout zu erkennen. Ein Software Bill of Materials im Format CycloneDX 1.6 oder SPDX 2.3 hilft bei der Komponentenprüfung, belegt aber für sich genommen noch keine tatsächlichen Datenflüsse.
Dasselbe gilt für den Shop. Der Beitrag Magento geerbt ohne Tests warum Security Fixes Privacy brechen macht einen Konflikt beim Patchen sichtbar; als CTO sollten Sie daraus keine pauschale Präferenz für Eigenentwicklung ableiten, weil ein eigener Shop dieselben blinden Flecken bei Modulen, Webhooks und Analyse-Skripten haben kann. Bei Magento 2.4.7 etwa können Kernsystem, Erweiterungen und eingebundene Browser-Skripte unterschiedliche Betreiber haben. Wer lediglich den Kern aktualisiert, hat damit weder die Empfänger von Checkout-Daten noch das Verhalten eines Zahlungs-Plugins geprüft.
Ich würde keinen Anbieter allein wegen einer ISO-27001-Zertifizierung auswählen, weil die Zertifizierung weder Ihren konkreten Datenfluss noch die Konfiguration Ihrer Instanz bestätigt. Verlangen Sie stattdessen eine aktuelle Empfängerliste, Angaben zu Unterauftragsverarbeitern, die abschaltbaren Telemetrie-Funktionen und ein Beispiel für eine Änderungsmitteilung. Diese Unterlagen müssen vor Vertragsabschluss vorliegen, weil fehlende Prüfrechte nach der Migration nur mit erheblichem Wechselaufwand nachverhandelt werden können.
Eigenentwicklung gewinnt nur, wenn das Team den Betrieb selbst prüfen kann
Option A: Eigenentwicklung. Sie gewinnt, wenn wenige, gut abgegrenzte Datenwege erforderlich sind und Ihr Team Releases, Abhängigkeiten und Vorfälle selbst untersucht. Ihr Preis besteht nicht nur aus Entwicklungszeit: Sie bezahlen dauerhaft für Patch-Management, Schlüsselverwaltung, Protokollierung und Bereitschaft bei Störungen. Ein eigener Checkout oder Desktop-Client ist keine Datenschutzmaßnahme, wenn im Fehlerfall niemand die ausgehenden Requests rekonstruieren kann.
Option B: Kauf eines Produkts mit Supportvertrag. Sie gewinnt, wenn der Anbieter Updates schneller und verlässlicher bereitstellt, als Ihr Team es leisten könnte, und zugleich technische Prüfung zulässt. Ihr Preis umfasst Lizenz, Integration, Vertragsprüfung und die Abhängigkeit von dessen Release-Zyklus. Ein günstiger Vertrag wird teuer, wenn Sie für einen Vorfall erst ein Support-Ticket eröffnen müssen, bevor Sie erfahren, welche externen Systeme Daten erhalten haben.
Der Vergleich sollte an einem konkreten Änderungsfall stattfinden: Ein Fehler in einer Bibliothek erfordert ein Update, während ein bestimmtes Telemetrie-Ziel gesperrt bleiben muss. Beim Eigenbau kann das Team den HTTP-Client ändern und mit Integrationstests prüfen, ob nur erlaubte Hosts erreicht werden. Beim Kauf muss der Anbieter dokumentieren, wie schnell er aktualisiert, ob Sie den Rollout verschieben dürfen und ob sich Telemetrie ohne Verlust sicherheitsrelevanter Updates deaktivieren lässt. Keine der beiden Optionen gewinnt automatisch: Eigenentwicklung bietet mehr Eingriffsmöglichkeiten, Kauf kann die laufende Wartung besser abdecken.
Setzen Sie dafür vorläufig 24 Stunden als zu verhandelnden Wert für die erste qualifizierte Reaktion auf einen kritischen Vorfall an; passen Sie ihn an Ihre tatsächliche Betriebsbereitschaft und die zugesagte Leistung des Anbieters an. Legen Sie als eigenen Planungswert zwei benannte Personen fest, die einen Datenfluss-Test nach jedem relevanten Release freigeben können; reicht Ihre Besetzung dafür nicht aus, gehört diese Lücke in die Kostenrechnung des Eigenbaus. Beide Zahlen sind Entscheidungsparameter, keine allgemein gültigen Sicherheitsgrenzen.
Prüfrechte sind wertvoller als unverbindliche Sicherheitsversprechen
Ein Vertrag sollte nicht nur „angemessene Sicherheit“ versprechen. Er muss festlegen, welche Informationen Sie im Betrieb erhalten und was bei Änderungen geschieht. Dazu gehören ein exportierbares Verzeichnis der Empfänger, eine Vorankündigung neuer Unterauftragsverarbeiter, abrufbare Audit-Logs und ein Verfahren zum Sperren einzelner Integrationen. Der Auftragsverarbeitungsvertrag nach DSGVO Artikel 28 klärt Verantwortlichkeiten; er ersetzt keine technische Möglichkeit, die vereinbarten Datenwege zu überprüfen.
Fragen Sie konkret nach OAuth-2.0-Scopes, SAML-2.0- oder OpenID-Connect-Anbindung und der Rotation von Zugangsdaten. Diese Standards sind nur dann ein Vorteil, wenn Berechtigungen eng vergeben und entzogen werden können: Ein dauerhaftes API-Token mit Zugriff auf alle Bestellungen macht eine ansonsten saubere Single-Sign-on-Integration zum schlechten Tausch. Für Web-Anwendungen gehören außerdem Content Security Policy (CSP) und dokumentierte externe Skriptquellen in die Abnahme, weil ein Skript im Browser Daten außerhalb der Serverprotokolle übertragen kann.
Für jede neue Empfängerdomain würde ich zunächst 30 Tage Vorlauf als veränderbaren Vertragsentwurf verlangen. Der passende Zeitraum hängt von Ihrem Release-Prozess ab; entscheidend ist, dass Ihr Team vor der Aktivierung prüfen und gegebenenfalls widersprechen kann. Definieren Sie daneben eine im Pilot zu kalibrierende Grenze: 95 % der von Ihnen als datenschutzrelevant eingestuften ausgehenden Requests sollen einem dokumentierten Zweck und Empfänger zuordenbar sein. Die restlichen Requests sind kein akzeptierter „Schwund“, sondern Fälle, die vor einer Freigabe untersucht werden müssen.
Werkzeuge wie OpenTelemetry und Sentry können bei der Untersuchung helfen, weil sie Aufrufe und Fehler über Systemgrenzen hinweg sichtbar machen. Ihre Konfiguration gehört aber selbst in die Datenschutzprüfung: Ein Trace kann URLs, Benutzerkennungen oder Payload-Ausschnitte enthalten. Prüfen Sie deshalb Sampling, Redaction und Aufbewahrung, statt Beobachtbarkeit als kostenloses Sicherheitsplus zu behandeln. OWASP ASVS 4.0.3 kann Anforderungen an Authentisierung und Protokollierung strukturieren; ob eine konkrete Anbieterinstanz diese Anforderungen erfüllt, zeigt erst ein Test mit Ihren Rollen und Daten.
Ein kleiner Datenweg-Pilot entlarvt teure Fehlentscheidungen früh
Vor einer Beschaffung sollten Sie einen begrenzten Ablauf auf beiden Optionen ausführen: anmelden, einen Datensatz anlegen, einen Fehler provozieren, ein Update einspielen und den Datensatz löschen. Verwenden Sie synthetische Daten, damit der Versuch selbst keine unnötigen personenbezogenen Informationen verteilt. Halten Sie dabei fest, welche DNS-Namen, HTTP-Ziele und Protokolle auftauchen und welche davon im Angebot oder Architekturentwurf stehen. Entscheidend ist die Abweichung zwischen behauptetem und beobachtetem Verhalten, nicht die bloße Anzahl der Requests.
Eine einfache Host-Prüfung kann aus einem Proxy-Export unbekannte Ziele markieren. Das folgende Python-3-Skript liest pro Zeile eine URL von der Standardeingabe und beendet sich mit Fehlerstatus, sobald ein Host nicht freigegeben ist:
import os
import sys
from urllib.parse import urlparse
allow = set(os.environ.get("EGRESS_ALLOW", "api.example.org").split(","))
urls = [line.strip() for line in sys.stdin if line.strip()]
blocked = [url for url in urls if urlparse(url).hostname not in allow]
for url in blocked:
print("Nicht freigegebener Host:", url, file=sys.stderr)
sys.exit(1 if blocked else 0)
Speichern Sie es beispielsweise als egress_gate.py; mit printf ‚https://api.example.org/orders\nhttps://telemetry.example.net/collect\n‘ | python3 egress_gate.py meldet es das zweite Ziel und liefert einen Fehlerstatus. Es ist bewusst nur ein Prüfbaustein: Umleitungen, wechselnde Hosts, DNS-Effekte und Daten in bereits erlaubten Requests erfasst eine Hostliste nicht. Für eine belastbare Abnahme brauchen Sie zusätzlich Netzwerkmitschnitte oder Proxy-Logs, eine Prüfung der Payloads und einen dokumentierten Abgleich mit den zugesagten Zwecken.
Lassen Sie Eigenbau und Kaufprodukt denselben Pilot durchlaufen. Bei Eigenentwicklung kostet das Instrumentieren zunächst Zeit, liefert aber einen Maßstab für künftige Releases. Beim Kauf zeigt der Versuch, ob der Anbieter Logs exportiert, Testinstanzen bereitstellt und Abweichungen nachvollziehbar erklärt. Nutzen Sie Dependabot oder Renovate für Hinweise auf Abhängigkeitsupdates und Sigstore cosign zur Prüfung signierter Artefakte, wo Ihre Lieferkette das unterstützt; keines dieser Werkzeuge sagt Ihnen jedoch, ob ein korrekt signiertes Update einen neuen Datenempfänger aktiviert.
Bewerten Sie schließlich nicht die schönste Demonstration, sondern die Zeit bis zur beantworteten Abweichung. Wenn ein fremder Host erscheint, sollte jemand einen Zweck nennen, die verantwortliche Komponente finden und den Datenfluss bis zur Klärung stoppen können. Fehlt beim Kauf die dafür nötige Einsicht, ist das kein kleiner Vertragsmangel. Fehlt sie beim Eigenbau, ist das Team für den versprochenen Kontrollgewinn noch nicht aufgestellt.
Die erste Entscheidung ist ein Test, keine Ausschreibung
Beauftragen Sie als Erstes einen Datenweg-Pilot mit synthetischen Daten und derselben Abnahme für Eigenbau und Kaufprodukt. Geben Sie beiden Seiten den konkreten Änderungsfall, die erlaubten Empfänger und die Pflicht zur Erklärung jeder Abweichung. Erst wenn Sie gesehen haben, wer einen unerwarteten Datenfluss finden und stoppen kann, sollten Sie Lizenzpreis und Entwicklungsaufwand gegeneinander rechnen. Sonst kaufen Sie womöglich Kontrolle ein, die nur auf dem Papier existiert.
