You've worked hard to push your app to production, but one overlooked detail can unravel everything: a dev certificate or test credential that quietly made the journey with it. The consequences range from failed App Store reviews to live security vulnerabilities. Knowing exactly where to look and what to look for is what separates a compromised release from a clean one. Dev credentials often reach production because there are no effective controls preventing them from doing so. Developers may embed a FedEx test key or an Apple Development certificate for temporary testing and then promote the same code without removing or replacing those credentials. Shared branches or configurations across environments can allow test flags or keys (for example, a "Test Environment: Yes" toggle) to persist into production. When issues arise, such as FedEx returning "Authentication Failed", credentials may be updated directly in the code without confirming that environment-specific boundaries are correctly enforced. In the absence of CI-based secret scanning, pre-commit hooks, or other automated checks, these developer-only assets can pass code review unnoticed and end up in the final production artifact. Pentestas is a penetration testing platform that also offers free-to-use security scanning tools built on the same methodology its testers use in manual engagements, covering everything from web and API surfaces to mobile binaries. Its IPA analyzer by Pentestas, an AI-driven penetration testing platform, is purpose-built for exactly this failure mode: it audits Info.plist configurations, ATS exceptions, and binary strings for hardcoded secrets and leftover test keys before a build ever reaches App Store review, giving you a static audit trail without waiting for a failed submission to find out. Once test credentials aren't fully blocked by automated safeguards, the build pipeline becomes the next control point, particularly around signing identities. Review CI/CD logs to confirm whether builds are using "Apple Development" or "Apple Distribution" certificates; an incorrect or mixed configuration can prevent successful production submissions. Examine environment variables such as CODE_SIGN_IDENTITY and DEVELOPMENT_TEAM for hardcoded values that may unintentionally apply development identities to release builds. Consider adding a pre-build step that enumerates Keychain certificates and fails the job if it detects only development certificates, missing private keys, or otherwise incomplete signing materials. In addition, verify branch-to-environment mappings so that TestFlight and App Store workflows use distinct and appropriate signing configurations and don't share settings intended for different stages. Provisioning profiles and entitlements can disclose development credentials just as clearly as certificates. If a production build contains an embedded development provisioning profile, it indicates that development signing assets were used in error. One key indicator is the get-task-allow entitlement, which permits debugger attachment and shouldn't be present in production binaries. Proper distribution builds must use App Store distribution profiles rather than development profiles that rely on device registration. The presence of a development profile UUID in a production IPA should be treated as a configuration error with security implications. Likewise, if the application continues to point to test or staging endpoints in a production release, it reflects a similar issue: deployment of artifacts intended for non-production environments into a production context, increasing the risk of unintended access or data exposure. Misconfigured provisioning profiles and entitlements are only one aspect of credential exposure risk. Your repository's Git history can contain test credentials that were committed long ago and never fully removed. To address this, scan the entire history, including all commits, tags, and branches, rather than limiting checks to the current state of the code. Use automated tools that combine pattern matching (for keys, tokens, and passwords) with entropy-based or heuristic analysis to identify less obvious leaks in configuration files, test fixtures, and CI/CD scripts. After detection, prioritize issues by verifying whether the exposed credentials are still valid and whether they're used in production or other sensitive environments. For external service integrations such as FedEx ShipStream, explicitly search for fields like "Test Key," "Production Key," and any configuration that controls environment switching. Schedule regular scans, for example every week, and compare new results against previous reports to identify newly introduced exposures and track remediation over time. Hardcoded staging endpoints can cause production traffic to be routed to non-production infrastructure, sometimes with real or long-lived API keys. These issues often don't break builds or tests, so they can remain unnoticed in a passing CI/CD pipeline. To reduce this risk, systematically scan configuration surfaces for hardcoded staging URLs and credentials, including files such as *.env, config.*, Secrets.*, and CI configuration directories like /.github/workflows/. This review should extend beyond the current working tree to the full Git history, including all branches and tags, because leaked endpoints and keys can persist in older commits even after being removed from the latest code. As part of the release process, introduce an automated commit-time or pre-merge gate using a secret-scanning tool such as gitleaks. When active keys are discovered, revoke and rotate them promptly, and then redeploy with updated configuration. This limits the impact window of any inadvertent exposure and helps ensure that production and staging environments remain clearly separated. When a development or distribution certificate is potentially compromised, assume it's already exposed and respond immediately. Start by revoking the affected certificate in your Apple Developer account and updating all associated provisioning profiles and build configurations to remove dependencies on it. If the private key is missing or believed to be compromised, don't reuse it. Instead, create a new certificate using the standard CSR process, export the corresponding .p12 file from Keychain Access, and import it on the Mac used for code signing. After revoking the certificate, remove the exposed credential from the project's Git history, not just from the latest files, to prevent recovery from previous commits. If you no longer control the private key or can't fully assess the scope of the compromise, contact [email protected] to request assistance with revocation and further guidance. Preventing development credentials from reaching production begins before any code is merged. Configure CI secrets scanning to run across the full Git history, including all tags and branches, so test keys are identified even if introduced earlier in the project. Implement pre-commit hooks and pull request checks with tools such as gitleaks to detect API keys, OAuth tokens, and certificate artifacts before they're added to the repository. Use strict separation of credentials by environment and require production systems to retrieve secrets exclusively from a dedicated Secrets Manager, not from version-controlled files. Limit the ability to create or manage distribution certificates to Admin or Account Holder roles to reduce the risk of unauthorized use. If a credential is committed, consider it exposed even if the file is later deleted, and rotate any potentially compromised secrets without delay. You've now got a clear roadmap for catching dev certificates and test credentials before they cause real damage in production. Audit your pipeline, inspect your provisioning profiles, scan your Git history, and lock down those hardcoded endpoints. Don't wait for a security incident to force your hand. Make these checks a standard part of every release cycle, and you'll keep developer credentials exactly where they belong, out of production.
How to Spot Dev Certificates and Test Credentials Accidentally Shipped to Production
Why Dev Credentials End Up in Production Code
Audit Your Build Pipeline for Debug Signing Identities
Provisioning Profiles and Entitlements That Signal Dev Credentials in Production
Scan Your App Repo's Full Git History for Exposed Test Credentials
Hardcoded Staging Endpoints and API Keys That Slipped Through
Revoke, Rotate, and Purge Compromised Dev Certificates Fast
How to Prevent Dev Credentials From Reaching Production Again
Conclusion