Protect CI/CD credentials from the code your pipeline builds
Separate untrusted checks from privileged releases, scope workflow permissions and review third-party actions as executable dependencies.
In brief
A build pipeline executes repository code and dependencies. Giving every build production secrets turns a code or dependency compromise into an access problem beyond the build itself.
Separate low-trust pull-request checks from the reviewed workflow that can publish or deploy.
Draw the trust boundary around inputs
Inspect who can change the code, workflow and artifacts used by the privileged job. Do not execute untrusted pull-request content in a privileged event simply to obtain secrets. Treat downloaded build artifacts as inputs with provenance, not automatically trusted because they came from another job.
Limit the credentials
Set explicit token permissions and prefer supported short-lived federation for deployment where appropriate. Scope stored secrets to the environment needing them. A test that only reads source should not receive registry publish or cloud administration credentials.
Review and recover
Pin third-party actions to reviewed immutable revisions where suitable, and maintain their updates. Protect workflow files and deployment branches. If a credential leaks, revoke it at its issuer and review affected runs; deleting a log or rerunning the pipeline does not invalidate the exposed value.
Before you act
Secret masking in logs is not a complete boundary: running code with access to a secret can still use it. Fork handling, workflow events and permissions must be understood for the platform you use.
What to do next
- List workflows, events, tokens and environments that can reach production.
- Give ordinary checks read-only or narrowly required permissions and no unnecessary secrets.
- Protect release changes, use reviewed actions and require appropriate approval for privileged environments.
