It should not, and you should design so it cannot. Run untrusted pull request builds without signing material, keep keystores and store keys in a protected release job, and treat any workflow that checks out fork code and also reads secrets as a hole. Platform defaults help, but they are not a plan.
Why mobile pipelines are a special case
A mobile pipeline holds unusually valuable secrets: an Android upload keystore, an iOS certificate, a store API key, a Play service account file. All of them are worth more than a typical test token. A pull request build only needs to compile and run tests, which needs none of them.
What the platform documentation says
A hosted CI service's secure-use guide gives several relevant points:
- Any user with write access to the repository has read access to all secrets configured in it, so credentials in workflows should have the least privileges required.
- Workflow triggers such as
pull_request_targetandworkflow_runrun with more privilege and must not explicitly check out untrusted code, including from forks. - Self-hosted runners can be persistently compromised by untrusted code, so they should almost never be used for public repositories.
A second page covers manual approval: workflow runs from a fork contributor may require approval from a maintainer with write access, and the doc tells reviewers to be especially alert to changes to the workflow files themselves.
Checklist for a safe split
| Control | What to do |
|---|---|
| Build identity | Give pull request builds no signing keys, no store credentials |
| Triggers | Avoid privileged triggers that check out fork code |
| Release job | Put signing in one job, reachable only from a protected branch or tag |
| Approval | Require reviewers on the environment holding production secrets |
| Workflow files | Review changes to pipeline files as carefully as app code |
| Runners | Use ephemeral runners for untrusted code |
| Caches | Do not let pull request builds write caches the release job restores |
The cache link people miss
Caches can carry an attack across the trust boundary. The same documentation set says low-trust triggers get read-only cache access by default, and warns that opening write access reintroduces cache poisoning, where a more privileged workflow later restores attacker-controlled content. Our post on what should never go in a mobile CI cache covers what to keep out.
Debug builds do not need release keys
For Android, build pull requests in debug configuration with the debug keystore, which holds nothing valuable. For iOS, build for simulator or with signing disabled. Production signing happens later, in a job that never ran contributor code.
Test it
Open a draft pull request from a throwaway fork and print whether signing variables exist, without printing their values. If any exist, your split is not working. Do this after changing workflow files, not just once.
Try it yourself
The demo shows how a gate decides whether a pull request may proceed. Click through it and look at what is checked before anything merges.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard offers policies and gates on pull requests, SBOM and dependency scanning, and reachability analysis. Try a free scan.
Quick check
Are secrets hidden from every pull request by default?
Defaults vary by trigger and by repository settings. Do not rely on them. Design the pipeline so pull request jobs have no signing material to read.
Is approval of fork runs enough?
It helps, but reviewers can miss a subtle change. Keep the secrets out of that job anyway.
Sources
- GitHub Docs: secure use reference
- GitHub Docs: approving workflow runs from forks
- GitHub Docs: dependency caching
Last reviewed: 19 October 2026.
