Audit a mobile pipeline by asking twelve questions about where signing keys live, who can release, what untrusted code can reach, and which inputs are pinned. If you can answer each with a file, a setting or a log, you have a defensible pipeline. If you answer from memory, you have a risk.
The twelve questions
| # | Question | What good looks like |
|---|---|---|
| 1 | Where does each signing key live? | One secret store, no copies on laptops or in repos |
| 2 | Who can read it? | A short, reviewed list |
| 3 | Can pull request builds see signing or store credentials? | No |
| 4 | Is production release behind a tag or manual job with approval? | Yes |
| 5 | Do branch builds and release builds use different credentials? | Yes, with narrower rights on branch builds |
| 6 | Which store credential type is used? | A scoped API key or service account, not a person's password |
| 7 | What do caches contain, and who can write them? | Downloads only, written by trusted jobs |
| 8 | Are build tools and dependencies pinned and reviewed? | Lockfiles committed, updates reviewed |
| 9 | Are Gradle or package checksums verified? | Yes, failing the build on mismatch |
| 10 | Do self-hosted runners clean up after each job? | Keychains and profiles deleted, ideally ephemeral |
| 11 | Could a secret appear in a log? | Debug off, nothing printed, rotation plan exists |
| 12 | Can you tell what built a given release? | Commit, lockfile hash and lane recorded |
How to gather evidence
For each question, note where the answer is stored: a pipeline file, a settings screen, a policy. Take dated screenshots or exports, and put them in one folder. That folder is your audit trail, and it also helps when a customer sends a security questionnaire. Be careful to describe only what is true today.
Reading the answers
Questions 3, 4 and 5 deal with blast radius: what a hijacked branch build can do. Questions 1, 2 and 6 are about the credentials themselves. Questions 7, 8 and 9 cover what flows into the build. Questions 10 to 12 cover the machine and the record.
If you can only fix three things this quarter, fix 3, 5 and 7. Keeping untrusted code away from credentials and caches is the highest return step in most pipelines.
What the platforms back up
The vendor documentation supports several of these. The hosted CI guidance says anyone with write access reads all repository secrets, warns against sensitive data in cache paths, and says self-hosted runners can be persistently compromised. The fastlane docs recommend read-only signing on CI and release triggers by tag or manual job. Google Play's permission model separates testing-track and production rights. For details, see posts on CI release rights and cache contents.
Make it recurring
Put the twelve questions in a calendar item each quarter and after any CI migration or staff change. Record who answered and the date. A pipeline audited once and never again drifts.
Try it yourself
The demo shows continuous monitoring turning a one-time check into an ongoing one. Click through it and look at how a change triggers a new finding.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard helps with questions 8, 9 and 12: SBOM and dependency scanning, reachability analysis, policy gates and compliance evidence automation. Try the free scan.
Quick check
How often should I run this audit?
Quarterly, and after major pipeline or staffing changes.
Which question matters most?
Question 3. If untrusted builds can reach signing or store credentials, the rest matters less.
Sources
- GitHub Docs: secure use reference
- fastlane docs: match
- fastlane docs: continuous integration
- Play Console permissions help
Last reviewed: 19 October 2026.
