Protect CI Deployment Secrets
Map which CI workflows can read deployment secrets, then test untrusted pull requests and least-privilege release jobs.
A deployment key in CI can reach production even when no developer knows its value. The workflow file, trigger type, runner, and repository permissions decide who can cause that key to be used. GitHub's secure-use reference warns that automatic redaction is not guaranteed and recommends least-privilege workflow permissions.
Start with a map of jobs that receive each secret. Include reusable workflows, organization-level secrets, environment protections, and third-party actions. Do not print a secret to see whether masking works. Use a synthetic marker in an owned test repository for leakage checks.
Workflow-secret map
| Job | Trigger | Credential | Scope | Gate |
|---|---|---|---|---|
| Pull-request test | Untrusted contribution | None | Read-only source | No deploy secret |
| Build | Protected branch | Package read token | One registry | Review dependency actions |
| Deploy | Approved release | Short-lived identity | One environment | Required reviewer |
| Rollback | Operator action | Deployment authority | Prior release only | Audit receipt |
Set GITHUB_TOKEN permissions at the job level. Pin or review external actions according to team policy. Avoid a workflow that checks out untrusted code and then runs it with a production secret in the same job. Protect release environments so a changed workflow cannot silently bypass the intended approval.
Controlled CI test
Open a synthetic pull request in an owned repository that attempts to read a marker secret. The test job must not receive it. Then run a protected release job and verify it can perform a harmless deployment check. Inspect logs, artifacts, caches, and failure traces for the marker. Check that a canceled job cannot later publish or deploy through a queued step.
Record the workflow commit, trigger, job permissions, secret reference, and result. A green build does not prove the secret boundary if the malicious job never ran. If the platform cannot offer the needed separation, split the build and deploy across trust levels. The review should end with exact jobs that can use each credential, not a blanket statement that CI secrets are secure.
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.