Redact Secrets From Build Logs
Test CI logs and failure traces with synthetic markers so deployment credentials and derived values do not appear in output.
A build may keep a secret out of the final bundle and still print it in CI output. Debug flags, shell tracing, failed HTTP calls, and dependency scripts are common paths. GitHub's secure-use reference says automatic redaction is not guaranteed, especially when values are transformed. Design logging so secret data never enters a message in the first place.
Map the jobs that receive credentials. Review commands around environment dumps, verbose clients, and exception reporting. A redaction pattern is a backup control, not a reason to log Authorization headers. Use a fake marker in an owned workflow to test the path.
Log exposure checklist
| Event | Safe output | Unsafe output |
|---|---|---|
| Missing credential | Secret name and job ID | Value or full environment |
| Provider 401 | Status and request ID | Authorization header |
| Build failure | Step and stack location | Raw command with key argument |
| Artifact upload | File name and size | Signed upload URL |
| Retry | Attempt count | Token-bearing request body |
Prefer passing credentials through protected environment variables or short-lived workload identity. Avoid command-line arguments when the process list or shell trace can show them. If a tool prints a raw request on error, turn that mode off or wrap the call in a safe adapter.
Marker test
Use a synthetic string with no authority. Put it in the same variable path as a deployment secret in an owned CI fixture. Exercise a successful run, a failed provider request, a canceled job, and a retry. Search job logs, annotations, artifacts, traces, and notification payloads for the exact marker and an encoded variant. Neither should appear.
Record the workflow commit, test marker hash, output stores checked, and remediation. Do not test with a real production key. If a live secret was logged, preserve the incident evidence without repeating the value, restrict access to the log, and revoke the key at the provider. A masked log alone does not prove that an artifact or downstream service did not receive the credential.
Make offboarding verifiable
Use the offboarding checklist to identify owners, revoke grants and verify the result. Discuss a scoped review of your application's access controls.
Sources
- GitHub Actions Secure Use ReferenceAccessed
- OWASP Logging Cheat SheetAccessed