16-3 · Kapitel 16 · 5 Min. Lesezeit

Warum Ihre Mobile-App-Pipeline eine Signatur benötigt (und wie Sie diese sicher verwalten)

Erfahren Sie, warum das Signieren von Android- und iOS-Apps in der CI/CD-Pipeline unverzichtbar ist und wie Sie Keystores, Zertifikate und Provisioning-Profile sicher verwalten – inklusive praktischer Checkliste.

Warum Ihre Mobile-App-Pipeline eine Signatur benötigt (und wie Sie diese sicher verwalten)

Sie haben gerade Ihre Android- oder iOS-App fertig gebaut. Der Build ist grün, die Tests bestanden, und Sie sind bereit für die Auslieferung. Doch bevor diese APK oder IPA auf einem Gerät landet, gibt es noch einen Schritt, der oft wie bürokratischer Overhead wirkt: das Signieren der App.

Es ist verlockend, das Signieren als lästige Pflichtaufgabe abzuhaken. Aber wenn Sie schon einmal einen Keystore verloren, ein Zertifikat an einem Freitagabend ablaufen sehen oder versehentlich ein Provisioning-Profil in ein öffentliches Repository committed haben, wissen Sie, dass hier der Ernst beginnt. Signieren ist keine bloße technische Formalität. Es ist die Sicherheitsschicht, die beweist, dass Ihre App von Ihnen stammt – und nicht von jemandem, der sie umgepackt oder Ihre Identität vorgetäuscht hat.

Was Signieren tatsächlich bewirkt

Wenn Sie eine App signieren, fügen Sie eine digitale Signatur hinzu, die die Binärdatei mit Ihrer Identität verknüpft. Diese Signatur wird vom Betriebssystem und vom App Store überprüft. Stimmt die Signatur nicht, wird die App nicht installiert oder der Store lehnt den Upload ab.

Bei Android erfolgt das Signieren mit einer Keystore-Datei. Diese Datei enthält einen privaten Schlüssel und ein digitales Zertifikat. Betrachten Sie es als Ihren offiziellen Stempel. Jedes Mal, wenn Sie eine APK oder ein AAB für die Veröffentlichung bauen, stempeln Sie diese mit Ihrem Keystore. Verwenden Sie später einen anderen Keystore, behandelt Android die App als völlig andere Anwendung – selbst wenn der Paketname identisch ist. Das bedeutet, dass Benutzer die App nicht über die bestehende Installation aktualisieren können. Sie müssten zuerst die alte Version deinstallieren und verlieren dabei alle lokalen Daten.

Bei iOS ist der Prozess komplexer. Sie benötigen zwei Dinge: ein Zertifikat und ein Provisioning-Profil. Das Zertifikat ist Ihre digitale Identität als Entwickler. Das Provisioning-Profil verknüpft das Zertifikat, die App-ID und die Liste der Geräte, die die App ausführen dürfen. Für die Verteilung über den App Store verwenden Sie ein Distributionszertifikat und ein App Store Provisioning-Profil. Für interne Tests oder die Entwicklung verwenden Sie ein Entwicklungszertifikat und ein Ad-hoc-Provisioning-Profil.

Das eigentliche Problem: Geheimnisse in einer Pipeline verwalten

Sobald Sie verstehen, was zum Signieren erforderlich ist, stellt sich die nächste Frage: Wie speichern Sie diese Anmeldeinformationen in Ihrer CI/CD-Pipeline, ohne sie in Ihren Code oder Ihre Konfigurationsdateien zu schreiben?

Die Antwort ist Secret Management. Aber lassen Sie uns zuerst klarstellen, was Sie nicht tun sollten.

Speichern Sie Keystores, Zertifikate oder Provisioning-Profile niemals in Ihrem Git-Repository. Diese Dateien sind Geheimnisse, keine Konfiguration. Landen sie in einem öffentlichen Repository, kann jeder Apps signieren und sich als Sie ausgeben. Landen sie in einem privaten Repository, haben Sie trotzdem ein Problem: Jeder Entwickler mit Repository-Zugriff hat nun Ihre Produktions-Signaturschlüssel. Das ist ein Sicherheits- und Prüfrisiko.

Verwenden Sie stattdessen den Secret Store Ihrer CI/CD-Plattform. GitHub Actions, GitLab CI, Jenkins und die meisten anderen Plattformen bieten integrierte Secret-Variablen. Sie können Ihren Keystore oder Ihr Zertifikat als base64-kodierten String hochladen, als Secret-Variable speichern und während des Pipeline-Laufs zurück in eine Datei dekodieren. Das Secret wird erst zur Laufzeit auf die Festplatte des Build-Rechners geschrieben und erscheint niemals in Logs.

Hier ein konkretes Beispiel für Android mit GitHub Actions:

- name: Keystore dekodieren
  run: echo "${{ secrets.KEYSTORE_BASE64 }}" | base64 --decode > app/release.keystore

Für iOS mit Fastlane und GitLab CI:

- name: Zertifikat dekodieren
  run: echo $MATCH_PASSWORD | fastlane match import --git_url $MATCH_REPO

Wenn Ihr Team mehr Kontrolle benötigt, ziehen Sie einen dedizierten Secrets Manager wie AWS Secrets Manager, Azure Key Vault oder HashiCorp Vault in Betracht. Ihre Pipeline ruft die Anmeldeinformationen zur Laufzeit von diesen Diensten ab. Dieser Ansatz bietet Ihnen Audit-Logs, Zugriffskontrolle und zentrale Rotation. Die Anmeldeinformationen liegen niemals innerhalb der Pipeline-Konfiguration selbst.

Hier ist ein vollständiges Bash-Skript, das den Keystore aus AWS Secrets Manager abruft, die APK mit jarsigner signiert und die Signatur überprüft:

#!/bin/bash
set -euo pipefail

# Keystore aus AWS Secrets Manager abrufen
KEYSTORE_SECRET=$(aws secretsmanager get-secret-value \
  --secret-id "mobile-app/keystore" \
  --query SecretString --output text)

echo "$KEYSTORE_SECRET" | base64 --decode > /tmp/release.keystore

# APK signieren
jarsigner -verbose -sigalg SHA256withRSA \
  -digestalg SHA-256 \
  -keystore /tmp/release.keystore \
  -storepass "$STORE_PASSWORD" \
  app-release-unsigned.apk \
  mykeyalias

# Signatur überprüfen
jarsigner -verify -verbose -certs app-release-unsigned.apk

# Aufräumen
rm -f /tmp/release.keystore

Dieses Skript stellt sicher, dass der Keystore niemals im Repository gespeichert wird, zur Laufzeit sicher abgerufen und unmittelbar nach dem Signieren gelöscht wird.

Zertifikatsablauf: Der stille Pipeline-Killer

Hier ist ein Szenario, das häufiger vorkommt, als es sollte. Ihre Pipeline läuft monatelang einwandfrei. Dann, eines Tages, schlägt ein Release-Build fehl. Sie durchforsten die Logs und stellen fest, dass das Signaturzertifikat abgelaufen ist. Die App, die bereits im Store ist, funktioniert auf den Geräten der Benutzer weiterhin einwandfrei. Aber Sie können keine neue Version hochladen. Der Store lehnt sie ab, weil die Signatur auf der neuen Binärdatei ungültig ist.

Android-Keystores und iOS-Zertifikate haben Ablaufdaten. Sie erneuern sich nicht automatisch. Ihre Pipeline sollte bevorstehende Abläufe erkennen und das Team alarmieren, bevor die Anmeldeinformationen unbrauchbar werden. Ein einfaches Skript, das das Gültigkeitsdatum des Keystores oder Zertifikats überprüft und eine Benachrichtigung an den Chat-Kanal Ihres Teams sendet, kann Sie vor einem blockierten Release bewahren.

Für Android können Sie das Ablaufdatum des Keystores wie folgt überprüfen:

keytool -list -v -keystore release.keystore -storepass $STORE_PASSWORD | grep "Valid until"

Für iOS enthält Fastlanes match-Tool einen --readonly-Modus, der das Zertifikatsablaufdatum anzeigt. Sie können auch den security-Befehl unter macOS verwenden:

security find-identity -v -p codesigning | grep "iPhone Distribution"

Eine praktische Checkliste für das Signieren in Ihrer Pipeline

Wenn Sie das Signieren zum ersten Mal einrichten oder Ihre aktuelle Konfiguration überprüfen, gehen Sie diese Checkliste durch:

Werden Keystores, Zertifikate und Provisioning-Profile außerhalb von Git gespeichert?
Werden die Signatur-Anmeldeinformationen im Secret Store der CI/CD-Plattform oder in einem externen Secrets Manager gespeichert?
Wird der base64-kodierte Keystore oder das Zertifikat als Secret-Variable und nicht in einer Konfigurationsdatei gespeichert?
Dekodiert die Pipeline das Secret nur zur Laufzeit in einem temporären Verzeichnis?
Werden die temporären Signaturdateien nach Abschluss des Builds bereinigt?
Überprüft die Pipeline das Ablaufdatum des Zertifikats und alarmiert das Team, bevor die Anmeldeinformationen ablaufen?
Gibt es einen dokumentierten Prozess für die Rotation oder Erneuerung der Signatur-Anmeldeinformationen?
Sind die Produktions-Signatur-Anmeldeinformationen auf eine kleine Gruppe vertrauenswürdiger Teammitglieder beschränkt?

Signieren ist nicht das Ende

Sobald Ihre App signiert ist, ist das Artefakt bereit für Tests. Aber eine signierte Binärdatei auf einem Build-Rechner ist nicht dasselbe wie ein getestetes Release. Mobile Apps können nicht vollständig durch das Lesen von Code oder das Ausführen von Unit-Tests allein überprüft werden. Sie müssen die signierte App auf Emulatoren, Simulatoren oder echten Geräten ausführen, um Probleme zu finden, die erst zur Laufzeit auftreten.

Der Signierschritt ist ein Tor. Er stellt sicher, dass das, was Sie testen und ausliefern wollen, wirklich von Ihnen stammt. Behandeln Sie ihn mit der gleichen Sorgfalt wie Ihre Produktionsdatenbank-Anmeldeinformationen. Denn in vielerlei Hinsicht ist er wertvoller: Ein verlorenes Datenbankpasswort bedeutet Wiederherstellung aus einem Backup. Ein verlorener Keystore bedeutet, dass Sie die Fähigkeit verlieren, Ihre App überhaupt zu aktualisieren.