Draw the path from contributor to production
Make the repository owner and deployment owner jointly accountable for the workflow inventory. For every workflow, record its trigger, checked-out revision, executable inputs, token permissions, secrets, runner and published artifacts. Include reusable workflows and scripts called indirectly. A job named lint or documentation can still execute contributor-controlled code and therefore deserves the same trust-boundary review as a build job.
Separate ordinary validation from release authorization. Identify when a public pull request, issue body, branch name or downloaded artifact enters a command or privileged job. GitHub’s secure-use guidance highlights untrusted code checkout and third-party actions. Our procedure is to trace the actual data flow rather than assume that an apparently safe event name makes the job safe.
Reduce persistent and ambient authority
Start workflow permissions at the minimum and grant narrowly defined exceptions per job. Pin external actions to reviewed full commit revisions and inspect the code they execute, including dependencies. Do not interpolate untrusted expressions directly into shell programs. Pass data through a safe input boundary and validate its intended format before allowing it to influence a privileged operation.
Use workload identity where supported, and configure the cloud trust policy to match the intended repository, environment and other relevant claims. GitHub documents OIDC as a way to exchange workflow identity for short-lived cloud credentials. The important control is the restriction on who may obtain what role; replacing a static key with a broadly trusted OIDC role does not remove excessive privilege.
Contain runner and artifact compromise
Treat self-hosted runners as machines that execute hostile code unless their inputs are tightly controlled. Avoid reusing a sensitive deployment runner for untrusted pull requests. Isolate credentials, workspaces and network access, and prefer an ephemeral lifecycle for jobs crossing a low-trust boundary. Review caches and artifacts as inputs whose contents can be changed, not as automatically trustworthy products of CI.
If a malicious action or job ran, identify the exact revision and authority available during that run. Preserve restricted copies of useful logs, revoke exposed credentials and examine cloud actions, repository changes and published packages. Updating the workflow is a code fix; it does not invalidate a secret already printed into a log or copied from a runner.
Test the negative paths before granting release access
Create a harmless test contribution containing dummy shell metacharacters in a title and a build script that attempts to access a designated test secret. Confirm that validation treats text as data and never receives release credentials. Use a non-production cloud role to prove that an unauthorized branch or environment cannot exchange an OIDC token for deployment access.
Record the result as a trust-boundary test, then repeat when triggers, reusable workflows, runner pools or deployment providers change. Review action updates through the normal change process and remove unused jobs. The release checklist should identify the tested source revision, verified artifact and deployment identity so an operator can establish what actually reached production.
Controls to take away
- CI is a privileged execution environment, not just a test dashboard.
- Short-lived credentials still require narrow trust and permissions.
- Test untrusted contributions without exposing real release secrets.
Work through the boundary.
These local worksheets turn the review questions into a plan. They do not inspect or change the actual account or environment.
Prepare the research environment ↗
Check authorization, source, credentials, egress and disposal for the actual lab boundary you will use.
Take this to your next review
Working checklist
Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.
0 of 5 reviewed
Sources & further reading
The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.
A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.