CI/CD deployment identity: short-lived access and narrow trust

Map the path from source to production

Identify repository write access, workflow definitions, reusable jobs, runners, artifact stores, approvals, and deployment targets. Record which step can change the code or configuration that production trusts. A narrowly scoped application runtime does not compensate for an unrestricted deployment identity.

Include emergency deployment and rollback paths. If they use different accounts or bypass ordinary controls, document why and how they are reviewed. A clear authority map helps both preventive review and incident containment.

References: [1] GitHub, [2] OWASP

Review federation and role trust together

GitHub documents how OIDC allows workflows to exchange identity information for short-lived cloud credentials. Review the claims and trust conditions used by the receiving provider, including the intended repository and environment context. Do not assume that enabling federation automatically narrows every caller.

Then review the downstream role or service account. It should have only the resources and actions needed for the deployment task. A short-lived credential with broad administrator authority can still cause major harm during its validity period.

References: [3] GitHub, [4] AWS

Separate jobs by trust and purpose

Keep untrusted code and outside pull-request content away from production secrets and privileged deployment contexts. Review event triggers, checked-out content, artifact handoffs, and reusable workflows. The review should establish what code executes at each point and under whose authority.

Constrain repository tokens and third-party actions according to the job’s needs. Pin and review action dependencies as appropriate, and maintain an update process. An approval step is useful only if the approved artifact and workflow context are the ones later deployed.

References: [1] GitHub, [5] OWASP

Verify the release and credential lifecycle

Test the intended deployment path and representative denied contexts in a safe environment. Confirm which identity is issued, what it can change, and how access expires or is revoked. Review whether old static credentials remain available as an unnecessary alternative path.

Connect the final artifact to its source revision, dependency state, and deployment record. Retain enough evidence to explain what reached production and rebuild it from trusted inputs if required. This is particularly valuable after a maintainer or pipeline compromise.

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

Your next steps

1. Document every identity and handoff from source changes to production deployment.
2. Review OIDC trust conditions and downstream role permissions together.
3. Separate untrusted jobs from privileged environments and artifact approval.
4. Book a scoped review of the application’s release-authority path.