GitHub Actions security checklist for release pipelines

Map triggers and workflow ownership

List workflows, reusable workflows, event triggers, runner types, and protected deployment environments. Identify who can change them and which jobs can access secrets or production authority. Treat the workflow definition as security-sensitive application infrastructure.

Review the relationship between the triggering event, checked-out code, and execution context. A pull-request job and a trusted release job do not necessarily have the same trust level. State which inputs are allowed to influence commands, artifacts, and deployment decisions.

References: [1] GitHub, [2] OWASP

Narrow tokens and secret exposure

Set repository-token and downstream permissions according to the job’s actual task. Keep production credentials out of jobs that only need to build or inspect untrusted changes. Review logs and generated outputs for accidental secret disclosure, and maintain a clear credential owner.

Where OIDC federation fits, review the cloud trust conditions and the role granted to the workflow. Short-lived credentials reduce one risk associated with stored keys, but they still need narrow scope. Confirm that legacy static secrets do not remain as an unnecessary alternative route.

References: [1] GitHub, [3] GitHub, [4] OWASP

Review third-party code and runner trust

GitHub recommends careful review of third-party actions and documents full-length commit-SHA pinning as an immutable reference for an action version. Maintain a process for reviewing updates rather than leaving a pinned dependency unchanged indefinitely. Reusable workflows deserve the same scrutiny.

Review runner persistence and isolation. A self-hosted runner executing less-trusted jobs may retain changes or expose later jobs if its lifecycle is not designed appropriately. The relevant question is what code can influence a future privileged step, not simply whether the runner is inside your network.

References: [1] GitHub, [5] OWASP

Verify the artifact and approval boundary

Establish which artifact was built, how it is identified, and what the deployment job trusts. An approval should relate to the intended source and artifact rather than a mutable label whose contents can change afterward. Include rollback and emergency release workflows in the map.

Use a safe environment to test legitimate release behavior and representative denied contexts. Retain evidence connecting source revision, dependency graph, build identity, artifact, and deployment. That evidence becomes important when investigating an unexpected publication or downstream package incident.

References: [6] npm, [7] GitHub, [8] NIST

Your next steps

1. Inventory workflow triggers, execution contexts, tokens, and deployment authority.
2. Review untrusted inputs, action references, and runner lifecycle.
3. Verify OIDC trust and artifact approval where they are used.
4. Book a scoped release-pipeline and application security review.