Not reliably. CI redaction looks for exact matches of known secret values, and a multi-line JSON file stored as one secret is the kind of structured data it handles badly. Keep the file out of logs by never printing it, pass it as a file path, and treat any appearance in a log as a leak.
What the documentation says
A hosted CI service's secure-use guide is direct about the limits. Because a secret value can be transformed in several ways, automatic redaction is not guaranteed. It warns against structured data as a secret: a blob of JSON, XML or YAML wrapping a secret value reduces the chance redaction works, because redaction largely relies on finding an exact match for the specific value. Its advice is to create individual secrets for each sensitive value.
The same guide adds that redaction is performed by the runner, so a secret is only redacted if it was used within a job and is accessible by the runner. If an unredacted secret is sent to a log, delete the log and rotate the secret. It also says that if a secret is used to generate another sensitive value, the generated value should be registered as a secret too.
Why Play keys are a risk here
A Google Play service account key is a JSON file with several fields, including a private key spanning many lines. Google says the credentials must be securely managed so they are not revealed to anyone not authorized. If you store the whole JSON as one secret, an error message that prints part of it, or a line-by-line echo, may not match the stored value and will appear in clear text.
Safer handling
| Practice | Why |
|---|---|
| Store the JSON in a secret manager | Central control and rotation |
| Write it to a temp file only when a step needs it | Short exposure |
| Pass the path, not the contents | Nothing to print |
| Delete the file at the end of the job | No leftovers on the runner |
| Mask derived values, such as access tokens | Redaction depends on registration |
| Turn off verbose or debug logging for release lanes | Debug output often dumps configuration |
Where leaks hide
- Debug flags that print config and environment.
- Error messages that echo the failing input.
- Build summaries or uploaded artifacts that include the workspace.
- Shell tracing switched on in a script.
A quick test: run the lane on a branch with a fake key, search the log for a distinctive piece of it, and confirm nothing shows. Do not use the real key for the test.
If it leaks
Delete the log, rotate the service account key, review recent API activity for that account and check who could read the log in the meantime. Our post on least-privilege Play service accounts limits what a leaked key can do, and the checklist in fastlane variables that are secrets covers the related credentials.
Where Safeguard fits
Safeguard does not offer secret scanning or log redaction. It covers dependency scanning, SBOMs, reachability analysis and policy gates. Try a free scan.
Quick check
Does masking make it safe to print the key?
No. Redaction is not guaranteed, so never print it.
Should I split the JSON into separate secrets?
The guide advises individual secrets for each sensitive value rather than a structured blob, but a file-based approach with careful handling is also common. Either way, avoid printing.
Sources
Last reviewed: 19 October 2026.
