Securely managing signing assets in CI/CD

WHAT THIS TESTS This is a security and automation question: do you understand that a signing certificate's private key is a credential that can impersonate your app, and do you know the established pattern for using it on CI safely.

A GOOD ANSWER COVERS The private key inside the P12 plus the provisioning profiles let anyone holding them sign builds as you, so they are secrets. The standard approach is to store them encrypted rather than in plaintext: fastlane match keeps the certificates and profiles in a private, encrypted Git repository or cloud storage, and the CI job decrypts them using a passphrase supplied through the CI provider's encrypted secret variables, never in the codebase. The job installs the identities into a temporary keychain it creates at the start of the run and deletes at the end, so secrets do not persist on shared agents. App Store Connect API keys, also stored as CI secrets, authenticate the TestFlight upload without a password. Access to the secret store and the encryption key is tightly scoped.

COMMON WRONG ANSWERS Committing the P12 and its password to the repository, even a private one, since history is permanent, clones spread it widely, and a single leak exposes your signing identity forever. Hardcoding the passphrase in a script. Leaving certificates in the shared system keychain on a multi-tenant runner.

LIKELY FOLLOW-UPS Why is repo history especially dangerous for leaked secrets? How does fastlane match keep machines in sync? How do App Store Connect API keys improve on Apple ID passwords for CI uploads?

ONE CONCRETE EXAMPLE Using fastlane match, your team stores the distribution certificate and App Store profiles encrypted in a dedicated private repo. The CI pipeline holds the match passphrase and an App Store Connect API key as masked secret variables. On each run the job decrypts the assets into a fresh temporary keychain, builds and signs the app, uploads to TestFlight via the API key, then tears down the keychain. Had the raw P12 and its password been committed to the app repo instead, any contributor or anyone who ever cloned it could sign malicious builds as your app, an irreversible exposure even after deletion because it remains in history.