Ihre Sicherheitsprüfung bleibt bei „verschlüsselt“ oder „temporär“ stehen, obwohl Datenresidenz und Löschung offen sind.
Schnellste Lösung: Xcode Cloud Datensicherheit im Unternehmen anhand der einzelnen Datentypen und Ihrer Richtlinien prüfen; wenn Nachweise für erforderliche Kontrollen fehlen, betroffene Jobs zurückhalten und Mac CI als Alternative bewerten.

Dieser Leitfaden ist für Sicherheits- und Compliance-Verantwortliche gedacht, die Cloud-Builds gegen interne Vorgaben prüfen.
CI-Plattformteams finden Prüfpunkte zu Repository-Zugriffen, Skripten und Build-Ausgaben.
IT- und Architekturverantwortliche erhalten Kriterien für eine Freigabe, eine eingeschränkte Nutzung oder eine alternative Mac-CI-Umgebung.

Für Sicherheits- und Compliance-Verantwortliche: Anforderungen in Kontrollen übersetzen

Behandeln Sie Verschlüsselung, temporäre Build-Umgebungen, Datenresidenz, Aufbewahrung und Auditierbarkeit als unterschiedliche Kontrollen. Ein Nachweis für eine davon belegt nicht automatisch die übrigen. Apple beschreibt für Xcode Cloud eine temporäre isolierte Build-Umgebung, nicht dauerhaft gespeicherten Quellcode sowie verschlüsselte Build-Ausgaben bei Übertragung und Speicherung. Diese Aussagen sind ein Prüfanfang, aber kein pauschaler Nachweis dafür, dass Ihre Unternehmensvorgaben erfüllt sind. Apples Sicherheitsbeschreibung zu Xcode Cloud

Beginnen Sie mit Ihrer Datenklassifizierung. Legen Sie fest, welche Repositories, Testdaten, Protokolle, Archive und Zugangsdaten überhaupt in einen Cloud-Build gelangen dürfen. Kennzeichnen Sie anschließend für jeden Datentyp die erforderlichen Kontrollen: zulässige Verarbeitungsorte, Zugriffskreis, Aufbewahrung, Löschung und erforderliche Prüfprotokolle. Die zuständigen Verantwortlichen können so konkret entscheiden, statt sich auf eine allgemeine Aussage über „Sicherheit“ zu verlassen.

Für die DSGVO-Prüfung gilt dasselbe Prinzip: Leiten Sie aus einer Verschlüsselungsaussage nicht ab, dass alle organisatorischen, vertraglichen und territorialen Anforderungen erfüllt sind. Halten Sie fest, welche interne Richtlinie oder vertragliche Grundlage Sie geprüft haben und wer die Abweichung freigeben darf. Wenn ein zwingender Nachweis fehlt, behandeln Sie das als offene Freigabebedingung, nicht als stillschweigend erfüllte Kontrolle.

Für Repository-Verantwortliche: Wird Quellcode dauerhaft gespeichert?

Apple erklärt, dass Quellcode in der temporären Build-Umgebung verwendet und nicht dauerhaft gespeichert wird. Das ist eine Aussage zur Speicherung des Quellcodes im beschriebenen Build-Kontext. Sie belegt weder den Verarbeitungsort noch eine bestimmte Löschfrist für alle zugehörigen Daten. Prüfen Sie außerdem getrennt, welche Daten ein Build durch Skripte an andere Ziele überträgt. Apples Sicherheitsbeschreibung zu Xcode Cloud

Die praktische Frage lautet deshalb nicht nur, ob Quellcode dauerhaft gespeichert wird. Sie müssen auch feststellen, welche Repositories freigegeben sind, welche Identität die Verbindung autorisiert und wie Sie den Zugriff nach einem Rollen- oder Beschäftigungswechsel entziehen. Apples Dokumentation beschreibt die Einrichtung der Quellcodeverwaltung und die Verbindung eines Repository-Anbieters mit Xcode Cloud. Nutzen Sie diese Anleitungen, um den tatsächlichen Einrichtungsweg mit Ihren Freigaben abzugleichen. Anleitung zur Einrichtung der Quellcodeverwaltung und Dokumentation zur Repository-Verbindung

Prüfen Sie die Autorisierung nicht nur bei der Ersteinrichtung. Halten Sie im internen Ablauf fest, wer neue Repositories verbinden darf, wie Änderungen dokumentiert werden und wer bei einem Austritt oder Aufgabenwechsel die Freigabe widerruft. Vermeiden Sie eine Freigabe, die weiter reicht als für den konkreten Build erforderlich. Wenn Sie ein selbst verwaltetes Repository oder einen besonderen Zugriffsweg einsetzen, bestätigen Sie anhand der geltenden Apple-Dokumentation und Ihrer Netzwerkrichtlinien, ob dieser Weg innerhalb Ihrer genehmigten Grenze liegt. Unterstellen Sie keine Unterstützung, die Sie nicht nachgewiesen haben.

Eine häufige Fehlannahme in der Abnahme: „Der Quellcode wird nicht dauerhaft gespeichert, also ist die Codegrenze eingehalten.“ Das greift zu kurz. Sobald ein Build Zugang zu einem Repository erhält, können zusätzliche Datenflüsse durch Build-Kommandos, Abhängigkeiten und externe Dienste entstehen. Dokumentieren Sie daher sowohl die Repository-Berechtigung als auch die Aktivitäten während des Builds.

Für CI-Plattformteams: Wie prüfen Sie temporäre Umgebungen und Skripte?

Eine temporäre Umgebung beschreibt, dass der Build in einer isolierten, nicht dauerhaft für den Quellcode vorgesehenen Umgebung ausgeführt wird. Daraus folgt nicht, dass während der Ausführung keine Daten außerhalb Ihrer Kontrolle verarbeitet werden. Der Build muss den benötigten Quellcode bereitstellen; zusätzlich können Build-Skripte Dateien, Variablen oder Testergebnisse an andere Dienste senden. Behandeln Sie diese Datenwege als eigene Integrationen, nicht als Teil der pauschalen Sicherheitszusage des Build-Dienstes.

Erstellen Sie zunächst eine Liste aller Skripte, die vor, während oder nach dem Build ausgeführt werden. Erfassen Sie je Skript Zweck, Eingaben, Netzwerkziele, Authentisierung und ausgegebene Dateien. Achten Sie insbesondere auf Uploads für Fehleranalyse, Testberichte, Paketablagen oder interne Benachrichtigungen. Apple dokumentiert die Verwendung benutzerdefinierter Build-Skripte; diese Dokumentation ersetzt jedoch nicht die Prüfung Ihrer konkreten Skriptinhalte und Zielsysteme. Apples Anleitung zu benutzerdefinierten Build-Skripten

Prüfen Sie Variablen und Geheimnisse getrennt. Ermitteln Sie, welche Werte ein Build benötigt, wer sie ändern darf und ob ein Skript sie in Protokolle oder Fehlermeldungen schreiben kann. Die Referenz zu Xcode-Cloud-Umgebungsvariablen hilft dabei, die vorgesehenen Variablen zu identifizieren. Sie beweist nicht, dass Ihre Skripte Geheimnisse sicher behandeln: Das ist durch Codeprüfung und einen kontrollierten Test zu verifizieren. Referenz zu Xcode-Cloud-Umgebungsvariablen

Führen Sie den Test mit nicht produktiven Zugangsdaten aus. Kontrollieren Sie anschließend die Skript-Ausgaben, Netzwerkziele und angelegten Dateien. Entfernen Sie unnötige Uploads, begrenzen Sie Zielsysteme auf freigegebene Endpunkte und verhindern Sie, dass Zugangsdaten in Ausgaben erscheinen. Wenn die Skriptprüfung nicht vollständig möglich ist, geben Sie die betreffenden Workflows nicht mit produktiven Geheimnissen frei.

Für App-Teams: Wie sind Logs und Build-Artefakte geschützt?

Apple erklärt, dass Build-Ausgaben, einschließlich Artefakten und Protokollen, während der Übertragung und im ruhenden Zustand verschlüsselt werden. Das ist eine konkrete Schutzinformation für diese Ausgaben. Sie liefert für sich genommen aber keine Antwort auf Ihre Anforderungen an Speicherort, Aufbewahrungsdauer, Zugriff durch Rollen oder Auditnachweise. Leiten Sie insbesondere keine bestimmte Löschfrist aus der Verschlüsselung ab. Apples Sicherheitsbeschreibung zu Xcode Cloud

Trennen Sie die Ausgaben im App-Projekt mindestens gedanklich in vier Gruppen: Build-Protokolle, Testergebnisse, Archive und sonstige Build-Dateien. In Protokollen können interne Pfade, Fehlerdetails oder versehentlich ausgegebene Variablen auftauchen. Testdaten können personenbezogene oder vertrauliche Informationen enthalten. Archive und andere Artefakte können ausführbare Dateien, interne Metadaten oder Signaturmaterial umfassen. Welche dieser Inhalte tatsächlich vorhanden sind, hängt von Ihrer Pipeline ab und muss im Projekt geprüft werden.

Legen Sie fest, wer Ergebnisse abrufen darf und welche Ausgaben in nachgelagerte Systeme kopiert werden. Prüfen Sie auch, ob ein Build-Bericht oder ein Artefakt außerhalb des CI-Dienstes weiter gespeichert wird. Für jede Kopie gelten dann die Regeln des jeweiligen Zielsystems; Apples Aussage zu Xcode-Cloud-Ausgaben ist kein Nachweis für dessen Speicher- oder Löschverhalten.

Die App-Teams sollten vor der Freigabe außerdem testen, ob Logs sensible Inhalte enthalten. Ändern Sie Skripte so, dass Geheimnisse und unnötige personenbezogene Daten nicht ausgegeben werden. Stimmen Sie die benötigten Testdaten auf die Datenklassifizierung ab. Wenn reale Kundendaten für einen Build nicht zwingend erforderlich sind, verwenden Sie einen freigegebenen Ersatzdatensatz. Halten Sie die Entscheidung fest, damit spätere Änderungen am Workflow erneut geprüft werden können.

Für Einkauf und Recht: Belegt Xcode Cloud die Datenresidenz?

Aus den hier beschriebenen Aussagen zu Verschlüsselung und temporärer Verarbeitung dürfen Sie keine bestimmte Datenresidenz, konkrete Löschfrist, territoriale Verarbeitung oder vollständige Auditfähigkeit ableiten. Diese Punkte müssen anhand der aktuell geltenden offiziellen Dokumentation, Vertragsunterlagen und Ihrer Beschaffungsprüfung separat geklärt werden. Fehlt ein belastbarer Beleg für eine zwingende Anforderung, dokumentieren Sie die offene Frage und eskalieren Sie sie an die dafür zuständige Stelle.

Halten Sie drei Arten von Nachweisen getrennt: veröffentlichte Sicherheits- und Einrichtungsdokumentation, vertragliche Unterlagen sowie Ihre interne Bewertung. Die erste Gruppe belegt, was Apple öffentlich zu Funktionen und Schutzmaßnahmen erklärt. Die zweite kann Bedingungen für den Dienst festlegen. Die dritte zeigt, ob Ihre Organisation die konkreten Bedingungen mit ihren Richtlinien abgeglichen hat. Vermischen Sie diese Belege nicht zu einer weitergehenden Zusicherung, als die jeweilige Quelle tatsächlich trägt.

Nutzen Sie für die Beschaffung ein Nachweisregister. Notieren Sie je Anforderung die Quelle, den belegten Umfang, offene Fragen, die verantwortliche Person und die Freigabeentscheidung. Prüfen Sie die Unterlagen erneut, wenn sich die Sicherheitsbeschreibung, Vertragsbedingungen oder die Nutzung des Workflows ändern. Für Konten und Rollen verwenden Sie die jeweils einschlägige Apple-Dokumentation und gleichen Sie die dort beschriebene Verwaltung mit Ihrem eigenen Berechtigungskonzept ab. Übersicht zu Accounts und Rollen in App Store Connect

Für Architekturverantwortliche: Freigabe, Einschränkung oder Mac CI

Treffen Sie die Entscheidung pro Workflow und Datenklasse. Eine pauschale Freigabe für alle Repositories ist unnötig, wenn einzelne Builds strengere Anforderungen an Datenzugriff, Netzwerkpfade, Aufbewahrung oder Auditnachweise haben. Behandeln Sie die folgenden Tabellen als Arbeitsunterlagen für Ihre interne Abnahme; sie enthalten keine zusätzliche Zusicherung über Xcode Cloud oder eine alternative Infrastruktur.

Datenbereich Was öffentlich belegt ist Was Sie intern zusätzlich prüfen
Quellcode Apple beschreibt eine temporäre isolierte Build-Umgebung und erklärt, dass Quellcode nicht dauerhaft gespeichert wird. Repository-Freigaben, autorisierte Identitäten, zulässige Datenklasse und die Behandlung zusätzlicher Datenwege
Build-Protokolle Apple zählt Protokolle zu den Build-Ausgaben und erklärt deren Verschlüsselung bei Übertragung und Speicherung. Inhalt, Abrufberechtigung, Weiterkopien, Aufbewahrung und Löschung nach Ihrer Richtlinie
Testergebnisse und Artefakte Apple nennt Artefakte und Protokolle als Beispiele für verschlüsselte Build-Ausgaben. Sicherheitsbeschreibung Sensible Testdaten, Archive, Signaturmaterial, Empfänger und nachgelagerte Speicherorte
Skriptübertragungen Apples Dokumentation beschreibt benutzerdefinierte Skripte und verfügbare Umgebungsvariablen. Skriptanleitung Tatsächliche Netzwerkziele, Uploads, Geheimnisse, externe Dienste und Skriptausgaben
Entscheidung Wann sie passt Freigabebedingung
Freigeben Die Datenklasse ist zulässig und erforderliche Kontrollen sind belegt. Repository-Rechte, Skripte, Ausgaben und interne Vorgaben sind geprüft und dokumentiert.
Eingeschränkt freigeben Einzelne Workflows sind geeignet, andere enthalten ungeklärte Daten oder Integrationen. Produktive Geheimnisse und nicht freigegebene Datentypen bleiben ausgeschlossen; offene Punkte haben Verantwortliche.
Zurückhalten und Mac CI prüfen Eine zwingende Anforderung an Datenzugriff, Netzwerk, Aufbewahrung oder Nachweise ist nicht geklärt. Vor der Migration werden Betrieb, Zugriff, Standortbedingungen und Zuständigkeiten für die konkrete Mac-CI-Umgebung ebenfalls geprüft.
Rolle Prüft Ergebnis für die Freigabe
Sicherheit und Compliance Datenklassifizierung, Gebietsvorgaben und erforderliche Nachweise Zulässige und ausgeschlossene Datenklassen
Repository-Verantwortliche Autorisierungen und Widerruf von Zugängen Freigegebene Repositories und zuständige Personen
CI-Plattformteam Skripte, Variablen, Netzwerkziele und Uploads Dokumentierte Build-Datenflüsse
App-Team Protokolle, Testergebnisse und Artefakte Begrenzte Ausgabeinhalte und Empfängerkreis
Einkauf und Recht Öffentliche Aussagen, Vertragsunterlagen und interne Prüfung Nachweisregister mit offenen Fragen
Architekturverantwortliche Gesamtrisiko und verbleibende Kontrolllücken Freigabe, Einschränkung oder alternative Ausführung

Arbeiten Sie die Freigabe anschließend mit dieser Checkliste ab:

  • [ ] Datenklassen für Quellcode, Testdaten, Protokolle und Artefakte festlegen.
  • [ ] Repository-Verbindungen und zugriffsberechtigte Identitäten mit dem genehmigten Umfang abgleichen.
  • [ ] Zuständigkeit und Verfahren für die Entziehung nicht mehr benötigter Zugriffe dokumentieren.
  • [ ] Benutzerdefinierte Skripte auf externe Ziele, Uploads und ausgegebene Geheimnisse prüfen.
  • [ ] Testberichte, Archive und Build-Protokolle auf sensible Inhalte und Weiterkopien untersuchen.
  • [ ] Aufbewahrung, Löschung, Datenresidenz und Auditnachweise als eigene Anforderungen bestätigen oder als offen markieren.
  • [ ] Für jede nicht erfüllte Pflichtkontrolle eine verantwortliche Person und eine Entscheidung festlegen.
  • [ ] Betroffene Workflows bis zur Klärung beschränken oder auf eine geprüfte Alternative verlagern.

Ein selbst verwalteter oder entfernter Mac-CI-Knoten kann sinnvoll sein, wenn Sie Build-Schritte, Zugriffe oder Netzwerkanbindungen anders kontrollieren müssen. Er beseitigt die Prüfaufgaben jedoch nicht: Sie müssen weiterhin Betrieb, Berechtigungen, Protokolle, Speicherorte und Löschprozesse festlegen. Vergleichen Sie die konkrete Umgebung und ihre Bedingungen, statt anzunehmen, dass „selbst verwaltet“ automatisch „konform“ bedeutet. Wenn Sie eine solche Alternative untersuchen, finden Sie bei MACCOME eine Übersicht zum Mac-Angebot; konkrete Einsatzbedingungen müssen Sie für Ihren Anwendungsfall gesondert verifizieren.

Wenn Ihre derzeitige Lösung auf Xcode Cloud beruht, bleiben mögliche Lücken bei nachweisbarer Datenresidenz, bestimmten Aufbewahrungs- oder Auditvorgaben und den von Skripten ausgelösten externen Datenwegen. Ein gemieteter Remote Mac kann Ihnen für ausgewählte Aufgaben eine separat zu prüfende Mac-CI-Umgebung bieten, ist aber nicht automatisch die bessere Wahl: Sie übernehmen zusätzliche Verantwortung für Zugriffsschutz, Betrieb und die vertragliche Prüfung von Standort- und Datenbedingungen. Für kurzzeitige Tests oder einen begrenzten Migrationspilot kann MACCOME eine Alternative zum sofortigen Kauf eigener Hardware sein. Prüfen Sie die konkreten Konditionen, bevor Sie produktive Daten verschieben; beginnen Sie dazu mit den Informationen zur Mac-Miete.