Verschlüsselung

Capgo bietet eine robuste End-to-End-Verschlüsselung für deine App-Bundles. So sind dein JavaScript code und deine Assets während der Übertragung und Speicherung geschützt. Dieses Verschlüsselungssystem gibt dir die volle Kontrolle über die Sicherheit deiner App, während der Komfort von Live Updates erhalten bleibt.

Übersicht

Das Verschlüsselungssystem von Capgo nutzt branchenübliche kryptografische Methoden, um deine Bundles vor unbefugtem Zugriff zu schützen. Wenn die Verschlüsselung aktiviert ist, werden deine Bundles verschlüsselt, bevor sie deine Entwicklungsumgebung verlassen, und bleiben verschlüsselt, bis sie von deiner App auf dem Gerät des Nutzers entschlüsselt werden.

Was die Verschlüsselung tatsächlich schützt: Im Gegensatz zu OTA-Systemen, die Updates nur signieren, verschlüsselt Capgo das hochgeladene Bundle vor der Speicherung und Auslieferung. Dies schützt den Inhalt des Bundles vor einfachem Zugriff während der Speicherung oder Übertragung und stellt sicher, dass nur jemand mit deinem Private Key ein gültiges verschlüsseltes Update erstellen kann. Es es nicht verhindert jedoch nicht das Reverse Engineering der ausgelieferten Web-Assets: Der vom Client zum Entschlüsseln der Updates verwendete Public Key ist in der App enthalten, sodass ein entschlossener Angreifer diesen mit ausreichendem Aufwand extrahieren und den Bundle-Inhalt einsehen kann.

Wann du Verschlüsselung benötigst

Wenn du ein Bundle ohne Verschlüsselung hochlädst, behandle es wie ein öffentliches Asset. Private Channels begrenzen zwar, welche Geräte ein Update erhalten, machen das hochgeladene Bundle aber nicht vertraulich. Verschlüsselung ist sinnvoll, wenn du besseren Schutz bei der Speicherung und Übertragung wünschst und sicherstellen willst, dass nur Inhaber des Private Keys gültige verschlüsselte Updates veröffentlichen können. Sie garantiert nicht, dass ausgeliefertes JavaScript, HTML oder CSS niemals eingesehen werden kann.

Bedrohungsmodell

Capgo Verschlüsselung schützt vor der Offenlegung von Bundles durch Capgo, Storage-Provider, CDNs oder jeden, der lediglich das verschlüsselte Auslieferungs-Artefakt sieht. Sie verhindert zudem, dass Dritte ohne deinen privaten Schlüssel gültige verschlüsselte Updates erstellen können. Da der öffentliche Schlüssel in der verteilten App eingebettet ist, damit der Client Updates entschlüsseln kann, könnte jemand mit Zugriff auf deine App-Binary und entsprechendem Aufwand das Material zum Inspizieren des Bundles extrahieren.

Tipp

Verschlüsselung ist besonders wichtig für:

• Apps, die sensible Daten oder Geschäftslogik verarbeiten
• Enterprise-Anwendungen mit Compliance-Anforderungen
• Apps in regulierten Branchen
• Unternehmen mit strengen Sicherheitsrichtlinien

Sicherheitsmodell

Vertraulichkeit in Bezug auf Capgo

Dein RSA-Privatschlüssel wird auf deinem Rechner generiert und dort gespeichert. Der Capgo CLI überträgt deinen privaten Schlüssel niemals, und Capgo speichert ihn nicht. Capgo speichert auch nicht deinen vollständigen RSA-Public-Key: Uploads enthalten nur einen kurzen key_id (die ersten 20 Zeichen des PEM-Bodys), damit die Channels mit dem verwendeten Schlüsselpaar übereinstimmen.

Verschlüsselte Full Bundles werden gespeichert und ausgeliefert als AES-128-CBC Ciphertext. Capgo Services, CDNs, Object Storage oder Akteure auf dem Delivery-Pfad, die nur die gehosteten Artefakte sehen, können dein JavaScript, HTML oder Assets ohne deinen Private Key nicht lesen.

Maximale Vertraulichkeit durch Capgo

Die Standard-Verschlüsselung schützt die Bundle- Inhalte bereits vertraulich in Capgo Storage und während der Übertragung. Wenn du zusätzlich verhindern willst, dass Capgo durch die Verknüpfung deines Update-Channels mit einer bestimmten Store-Binary Rückschlüsse zieht, folge dieser Anleitung.

Nutze eine dedizierte Capgo App-ID. Setzen Sie plugins.CapacitorUpdater.appId (deine Capgo app_id) an einen Wert, der es nicht identisch mit deiner iOS Bundle ID oder Android Application ID ist. Store- und MDM-Builds betten deinen RSA-Public-Key in capacitor.config. Wenn der Capgo app_id mit dem Store-Package-Namen übereinstimmt, lässt sich die Capgo App leichter mit einer veröffentlichten Binary verknüpfen, die diesen Public Key enthält. Eine separate Capgo App ID verhindert diese direkte Verknüpfung.

Capgo Builder und den Public Key. Capgo Builder lädt dein Projekt als Zip mit capacitor.config (und dem Native Tree) hoch, inklusive plugins.CapacitorUpdater.publicKey danach key save. Um den Public Key aus Builder-Uploads fernzuhalten:

• Erstelle Native Builds lokal oder in deiner eigenen CI, wenn die Vertraulichkeit gegenüber Capgo entscheidend ist, und vermeide es, diese Trees über den Capgo Builder hochzuladen, solange der Public Key in der Config steht. oder
• Füge den Public Key mit key save erst hinzu, nachdem alle Builder-Uploads, die den Key nicht preisgeben dürfen, abgeschlossen sind, oder
• Wenn du den Capgo Builder für Native Builds nutzt, bietet dieser Workflow starke Integrität (signierte Checksums), aber gehe es nicht nicht von Vertraulichkeit durch Capgo aus, sobald der Public Key in einem Builder-Upload enthalten ist.

Delta-Uploads verschlüsseln. Delta-(Teil-)Dateiinhalte sind Klartext, es sei denn, du nutzt @capgo/capacitor-updater 6.14.4 oder neuer (Teilverschlüsselung ist bei verschlüsselten Uploads auf unterstützten Updater-Versionen automatisch aktiviert) oder übergib --encrypt-partial auf bundle upload. Selbst bei Teilverschlüsselung Dateinamen in Delta-Manifesten aufgeführte Dateinamen sind nicht verschlüsselt; nur die Hashes pro Datei sind RSA-wrapped.

Integrität

Nach der Entschlüsselung berechnet der Updater SHA-256 über das Bundle und vergleicht ihn mit der aus der RSA-wrapped-Signatur gewonnenen Prüfsumme. Bei einer Abweichung wird das Bundle entfernt und nie aktiviert:

• Android prüft nach der Entschlüsselung die Prüfsumme und bevor das Entpacken des Archivs.
• iOS entschlüsselt und entpackt zuerst, dann wird die Prüfsumme verifiziert bevor das Bundle kann aktiviert werden.

Ist ein Public Key konfiguriert, werden fehlende oder nicht korrekt RSA-signierte Checksums abgelehnt.

Key-Handling

Für jeden vollständigen Zip-Upload generiert CLI einen neuen, zufälligen AES-128 Session-Key und 16-Byte IV, verschlüsselt das Bundle mit AES-128-CBC, und verschlüsselt den Session-Key mit deinem RSA-2048 Private Key unter Verwendung von PKCS#1 v1.5 Typ 1 Padding. Geräte stellen den AES-Key mit dem in der App eingebetteten RSA-Public-Key wieder her. Keys und IVs werden bei separaten CLI Bundle-Uploads nicht wiederverwendet. Innerhalb eines Delta-Uploads nutzen alle verschlüsselten Teildateien den Session-Key und IV dieses Uploads.

Der für die Entschlüsselung verwendete Public Key ist in deiner ausgelieferten App eingebettet. Der unverschlüsselte Bundle-Inhalt ist auf Geräten verfügbar, die deine App über denselben Entschlüsselungspfad ausführen, den auch der Updater nutzt – vergleichbar mit anderen Assets im App-Package.

Fehler und Reporting

Fehler bei der Entschlüsselung oder beim Checksum-Abgleich werden als Stats-Events (download_fail, checksum_fail, decrypt_fail) an den Capgo Stats-Endpoint oder deinen Self-hosted Stats-Handler. Stats werden vom Gerät gesendet; basierend auf dem Erfolg oder Fehlschlagen der Entschlüsselung werden keine Daten an Drittanbieter-Bundle-Hosts gemeldet. Jeder Versuch ist in der Regel ein vom Gerät initiierter Full-Download, weshalb Probing im Padding-Oracle-Stil unpraktisch ist und modifizierter Plaintext weiterhin die signierte Checksumme verletzt.

Zukünftige Härtung

Ein zukünftiges Major-Release könnte ein versioniertes Format mit AES-GCM und RSA-PSS über dem Hash als Defense-in-Depth-Maßnahme neben dem aktuellen Design hinzufügen. Dies wäre ein schrittweiser Härtungsschritt und kein Notfall-Security-Fix für das aktuelle Format.

So funktioniert die Verschlüsselung

Capgo nutzt einen hybriden Verschlüsselungsansatz, der RSA- und AES-Verschlüsselung für optimale Sicherheit und Performance kombiniert:

1. Key-Generierung

• Privater Schlüssel: Wird sicher in deiner Entwicklungsumgebung generiert und gespeichert (wird zur Verschlüsselung genutzt)
• Public Key: Wird aus deinem Private Key abgeleitet und in der Capacitor Config deiner App gespeichert (wird zur Entschlüsselung genutzt)
• Session-Keys: Zufällige AES-Keys, die für jeden Bundle-Upload generiert werden

2. Verschlüsselungsprozess

1. Für jeden Bundle-Upload wird ein zufälliger AES-Session-Key generiert
2. Dein Bundle wird mit dem AES-Session-Key verschlüsselt
3. Der Bundle-Checksum wird berechnet
4. Sowohl der AES-Session-Key als auch der Checksum werden gemeinsam mit deinem RSA-Private-Key verschlüsselt (erzeugt die „Signatur“)
5. Das verschlüsselte Bundle und die verschlüsselte Signatur werden gespeichert

Der Checksum wird zusammen mit dem AES-Key verschlüsselt, um Manipulationen zu verhindern. Da nur dein RSA-Private-Key diese Signatur erstellen kann und nur der entsprechende Public-Key sie entschlüsselt, wird sichergestellt, dass sowohl der AES-Session-Key als auch der erwartete Checksum authentisch sind und nicht von einem Angreifer verändert wurden.

3. Entschlüsselungsprozess

1. Deine App lädt das verschlüsselte Bundle und die verschlüsselte Signatur herunter
2. Das Capgo SDK nutzt deinen RSA-Public-Key (in der App gespeichert), um die Signatur zu entschlüsseln
3. Dadurch werden der AES-Session-Key und der ursprüngliche Checksum sichtbar
4. Der AES-Session-Key wird verwendet, um das Bundle zu entschlüsseln
5. Ein Checksum des entschlüsselten Bundles wird berechnet und zur Integritätsprüfung mit dem ursprünglichen Checksum verglichen

Dieser Prozess stellt sicher, dass ein Angreifer selbst bei einem abgefangenen, verschlüsselten Bundle weder den AES-Session-Key manipulieren noch einen gefälschten Checksum bereitstellen kann, da er Ihren Private Key benötigt, um eine gültige Signatur zu erstellen, die der Public Key entschlüsseln kann.

Tipp

Da RSA große Datenmengen nicht effizient verschlüsseln kann, wird AES für die eigentliche Bundle-Verschlüsselung genutzt, während RSA den AES-Key absichert und die Integrität durch das Signieren des Checksums gewährleistet.

Capgo vs. andere Plattformen

Feature	Capgo	Andere OTA-Plattformen
Bundle-Inhalt	Verschlüsselt bei Speicherung/Übertragung; durch Reverse Engineering der App-Binary dennoch einsehbar	Öffentlich lesbar
Sicherheitsmethode	Echte Ende-zu-Ende-Verschlüsselung	Code Signierung nur
Datenschutz-Level	Starker Schutz bei Übertragung und Speicherung; kein Anti-Reverse-Engineering	Plattform kann auf dein code zugreifen
Schutz	Inhalt + Integrität + Authentizität	Nur Integrität + Authentizität

Warum das wichtig ist:

• Code Signierung verifiziert nur, dass Updates nicht manipuliert wurden und von der richtigen Quelle stammen
• Capgo Verschlüsselung schützt das Bundle während der Speicherung und Auslieferung. Gefälschte, verschlüsselte Updates werden dadurch massiv erschwert, da Angreifer deinen Private Key benötigen würden
• Reverse Engineering bleibt weiterhin möglich nach dem App-Release, da der Client den öffentlichen Schlüssel zum Entschlüsseln und Laden des Updates enthält

Verschlüsselungsmethoden

Capgo nutzt Encryption V2 als Standard-Verschlüsselungsmethode:

Verschlüsselung V2 (aktueller Standard)

• Nutzt RSA-4096 für erhöhte Sicherheit
• AES-256-GCM für authentifizierte Verschlüsselung
• Bietet Integritätsprüfung
• Bessere Performance und Sicherheit

Verschlüsselung V1 (veraltet)

• Nutzt RSA-2048 zur Schlüsselverschlüsselung
• AES-256-CBC für die Bundle-Verschlüsselung
• In der aktuellen CLI nicht mehr verfügbar
• Legacy-Apps mit V1 müssen auf V2 migrieren

Achtung

Verschlüsselung V1 wird in der aktuellen Capgo CLI nicht mehr unterstützt. Wenn du V1-Verschlüsselung nutzt, musst du auf V2 migrieren. Siehe den Migrationsleitfaden für detaillierte Anweisungen.

Verschlüsselung einrichten

Schritt 1: Verschlüsselungsschlüssel generieren

Generiere zuerst deine Verschlüsselungsschlüssel mit dem Capgo CLI:

# Generate new encryption keys (creates files in current directory)
npx @capgo/cli@latest key create

Dadurch werden erstellt:

• .capgo_key_v2: Dein privater Schlüssel (behalte diesen sicher!)
• .capgo_key_v2.pub: Your public key (used by your app)

Diese Dateien werden im aktuellen Verzeichnis erstellt, in dem du den Befehl ausführst.

Achtung

Wichtige Hinweise zum Speicher:

• Privater Schlüssel (.capgo_key_v2): Niemals in die Versionsverwaltung committen. Diese Datei muss sicher aufbewahrt werden und darf nur für die Verschlüsselung beim Bundle-Upload verwendet werden.
• Öffentlicher Schlüssel (.capgo_key_v2.pub): Dies kann sicher in die Versionsverwaltung committet werden, da es sich um ein Backup deines Public Keys handelt.
• File Location: Keys werden im aktuellen Verzeichnis erstellt, in dem du den key create command.
• Public Key in der Config: Du musst key save ausführen, um den Public Key in deiner Capacitor Config zu speichern, damit die mobile App ihn nutzen kann.

Speichere den Private Key für den Produktivbetrieb sicher (z. B. in Umgebungsvariablen oder Key-Management-Services) und entferne ihn nach der Einrichtung aus deinem lokalen Projekt.

Schritt 2: Public Key in der Capacitor Config speichern (Erforderlich)

Du musst deinen Public Key in der Capacitor Config speichern, damit deine App die Bundles entschlüsseln kann:

# Save public key from file to Capacitor config (required)
npx @capgo/cli@latest key save --key ./.capgo_key_v2.pub

# Or save public key data directly
npx @capgo/cli@latest key save --key-data "$CAPGO_PUBLIC_KEY"

Schritt 3: Capacitor Plattform synchronisieren (Erforderlich)

Nachdem du den Public Key gespeichert hast, musst du musst Synchronisiere die Capacitor-Plattform, um die aktualisierte Config in den Native Layer zu kopieren:

# Sync the platform to copy config to native
npx cap sync

Achtung

Erforderliche Schritte:

1. Der key save Der Befehl speichert den Public Key in deiner Capacitor-Config
2. npx cap sync Kopiert diese Config in den Native Layer, damit die Mobile-App darauf zugreifen kann
3. Ohne beide Schritte kann deine App die verschlüsselten Updates nicht entschlüsseln

Bundles verschlüsseln

Methode 1: Verschlüsselung beim Upload

Der einfachste Weg ist die Verschlüsselung während des Upload-Prozesses:

# Upload with automatic encryption
npx @capgo/cli@latest bundle upload --key-v2

# For external storage, you must encrypt first (see Manual Encryption Workflow below)

Methode 2: Manueller Verschlüsselungs-Workflow

Für mehr Kontrolle können Sie Bundles manuell verschlüsseln:

1. Erstellen Sie ein Zip-Bundle:

   npx @capgo/cli@latest bundle zip com.example.app --path ./dist --key-v2

2. Verschlüsseln Sie das Bundle:

   npx @capgo/cli@latest bundle encrypt ./com.example.app.zip CHECKSUM_FROM_STEP_1

3. In deinen Speicher (z. B. S3) hochladen und bei Capgo registrieren:

   # First upload the encrypted bundle to your storage (e.g., AWS S3)
   aws s3 cp ./encrypted-bundle.zip s3://your-bucket/encrypted-bundle.zip
   
   # Then register with Capgo using the external URL
   npx @capgo/cli@latest bundle upload --external https://your-storage.com/encrypted-bundle.zip --iv-session-key IV_SESSION_KEY_FROM_STEP_2

Schlüsselmanagement

Keys sicher speichern

Optionen für den Private Key:

1. Datei-basiert (lokale Entwicklung):

   # Key stored as .capgo_key_v2 file in project root
   npx @capgo/cli@latest bundle upload --key-v2

2. Umgebungsvariable (CI/CD):

   # Store in environment variable for CI
   export CAPGO_PRIVATE_KEY="$(cat .capgo_key_v2)"
   npx @capgo/cli@latest bundle upload --key-data-v2 "$CAPGO_PRIVATE_KEY"

Public Key Setup (Erforderlich):

# Must save public key to Capacitor config for mobile app
npx @capgo/cli@latest key save --key ./.capgo_key_v2.pub

Produktionsumgebung:

• Private Keys in sicheren Key-Management-Services speichern (AWS KMS, Azure Key Vault, etc.)
• CI/CD Secret Management für private Keys nutzen
• Private Keys niemals in die Versionsverwaltung committen

Key-Nutzung:

• Privater Schlüssel: Wird von CLI für die Verschlüsselung beim Bundle-Upload verwendet (geheim halten)
• Public Key: In der App-Konfiguration zur Entschlüsselung auf dem Gerät gespeichert (Commit sicher)

Rotation nach Kompromittierung des privaten Schlüssels

Rotieren Sie das Schlüsselpaar, wenn der Verdacht besteht oder bestätigt wurde, dass der private Schlüssel kompromittiert wurde. Eine routinemäßige Rotation nach Kalender nicht erforderlich. Dies ist eine Native-Key-Migration, keine reine OTA-Änderung.

1. Generieren Sie ein Ersatz-Schlüsselpaar:

   npx @capgo/cli@latest key create

2. Speichern Sie den neuen öffentlichen Schlüssel in Ihrer Capacitor Config:

   npx @capgo/cli@latest key save --key ./.capgo_key_v2.pub

3. Sync und Release des Native Builds: Ausführen npx cap sync, dann eine neue native App-Version mit dem neuen Public Key verteilen.

4. Ziel auf die neue native Version setzen: Geräte mit der alten nativen Binary können Updates mit dem neuen Key nicht entschlüsseln. Nutze Version-Targeting , um Bundles mit dem neuen Key nur für die neue native Version freizugeben, während der Rest über den Store oder MDM aktualisiert wird.

5. Upload Secret wechseln: Sobald das native Release live ist, ersetze den Private Key in der CI und lade nur Bundles hoch, die für native Versionen mit dem neuen Public Key bestimmt sind.

Achtung

Wenn der Private Key kompromittiert wurde, beende seine Nutzung sofort. Bestehende Installationen mit dem alten Public Key benötigen ein Update über den nativen Store oder MDM, bevor sie Bundles empfangen können, die mit dem Ersatz-Key verschlüsselt sind.

Sicherheits-Best-Practices

Key-Sicherheit

• Private Keys niemals teilen zwischen Umgebungen oder Teammitgliedern
• Verschiedene Keys verwenden für unterschiedliche Umgebungen (dev, staging, production)
• Nach Kompromittierung rotieren: Ersetze das Key-Paar, wenn der Private Key möglicherweise oder bestätigt kompromittiert ist; eine routinemäßige Rotation nach Kalender ist nicht erforderlich
• Keys sicher speichern Verwendung sicherer Key-Management-Systeme

Bundle-Sicherheit

• Immer prüfen die Bundle-Integrität nach der Entschlüsselung
• Überwachen auf ungewöhnliche Download-Muster oder Fehler
• HTTPS verwenden für alle Bundle-URLs (erforderlich für mobile Apps)
• Implementieren ein ordnungsgemäßes Error-Handling bei Entschlüsselungsfehlern

Zugriffskontrolle

• Zugriff beschränken auf Verschlüsselungsschlüssel nur für autorisiertes Personal
• Rollenbasierte Zugriffskontrolle nutzen für Key-Management-Operationen
• Audit Key-Nutzung und Zugriff regelmäßig prüfen
• Implementieren ordnungsgemäßer Backup- und Recovery-Verfahren

Fehlersuche bei der Verschlüsselung

Häufige Probleme

Fehler beim Entschlüsseln:

• Prüfen, ob der Private Key zum verwendeten Public Key passt
• Stellen Sie sicher, dass der ivSessionKey korrekt ist
• Verwenden Sie Encryption V2 (V1 wird nicht mehr unterstützt)

Fehler im Zusammenhang mit Keys:

• Prüfen Sie das Format des Private Keys (PEM-Format)
• Stellen Sie sicher, dass der Key nicht beim Speichern/Übertragen beschädigt wurde
• Prüfen Sie die Berechtigungen des Keys in Ihrer App-Konfiguration

Performance-Probleme:

• Große Bundles benötigen länger für die Verschlüsselung/Entschlüsselung
• Nutze Delta-Updates, um die Bundle-Größe zu reduzieren
• Überwache die Device-Performance während der Entschlüsselung

Debug-Commands

Verschlüsselungsstatus prüfen:

npx @capgo/cli@latest app debug

Verschlüsselungs-/Entschlüsselungs-Workflow testen:

# Test the complete workflow: zip → encrypt → decrypt → unzip
npx @capgo/cli@latest bundle zip com.example.app --key-v2
npx @capgo/cli@latest bundle encrypt ./com.example.app.zip CHECKSUM --json
npx @capgo/cli@latest bundle decrypt ./encrypted-bundle.zip IV_SESSION_KEY

Compliance und Standards

Die Verschlüsselung von Capgo folgt Industriestandards:

• AES-256: FIPS 140-2-zertifizierter Verschlüsselungsalgorithmus
• RSA-4096: Starke asymmetrische Verschlüsselung zum Schutz der Keys
• GCM-Modus: Gewährleistet Vertraulichkeit und Authentizität
• Sichere Zufallszahlen: Kryptografisch sichere Zufallszahlengenerierung

Dadurch ist Capgo ideal für Anwendungen, die Compliance mit folgenden Standards erfordern:

• DSGVO (Datenschutz-Grundverordnung)
• HIPAA (Health Insurance Portability and Accountability Act)
• SOC 2 (Service Organization Control 2)
• ISO 27001 (Informationssicherheitsmanagement)

Performance-Aspekte

Verschlüsselungs-Overhead

• Bundle-Größe: Verschlüsselte Bundles sind etwas größer (~1-2 % Overhead)
• Verarbeitungszeit: Verschlüsselung/Entschlüsselung verursacht minimale Latenz
• Speicherverbrauch: Temporärer Anstieg während der Verschlüsselungs-/Entschlüsselungsvorgänge

Optimierungstipps

• Nutze Delta-Updates, um den verschlüsselten Datentransfer zu minimieren
• Optimiere deine Bundle-Größe, indem du Bilder in das WebP-Format konvertierst
• Minifiziere JavaScript- und CSS-Dateien vor dem Bundling
• Entferne ungenutzte Dependencies und code
• Überwache die Performance auf älteren oder langsameren Geräten

Nächste Schritte

• Mehr über Eigener Speicher um Verschlüsselung mit der eigenen Infrastruktur zu nutzen
• Entdecken Channels um verschlüsselte Bundles über Umgebungen hinweg zu verwalten
• Einrichten CI/CD-Integration um verschlüsselte Deployments zu automatisieren

Weiter mit Verschlüsselung

Wenn du es nutzt Verschlüsselung um Sicherheit und Compliance zu planen, verbinden Sie es mit Compliance für das Implementierungsdetail in Compliance, Capgo Security Scanner für den Produkt-Workflow im Capgo Security Scanner, Capgo Sicherheit für den Produkt-Workflow in Capgo Security, Capgo Trust Center für den Produkt-Workflow im Capgo Trust Center, und Organisationssicherheit für die Implementierungsdetails in Organization Security.