GitHub Actions OIDC Cloud Trust: A Test Matrix

GitHub Actions OIDC lets a workflow exchange a short-lived identity token for cloud credentials. AWS warns that a GitHub OIDC role without a subject condition restricted to the intended organization or repository can be assumed from outside it. GitHub Docs and AWS IAM make the trust policy a precise test target.

Quick answer. A GitHub Actions OIDC cloud trust test should map each deployment workflow to a cloud role, then verify repository, branch or environment subject conditions and the role's permissions. Use controlled workflows and roles for denied cases. Stingrai can scope a human-led cloud and application assessment around these customer-owned CI/CD trust edges.

Removing a long-lived cloud secret is useful, but the exchange must still answer which workflow may obtain the role and what that role may do. A token from a valid OIDC issuer does not prove that the repository, branch, environment or job is authorized. The test plan must evaluate the GitHub claims and the cloud provider policy together, with one safe negative case for each intended boundary.

The buyer's test matrix

This matrix is a starting point for a scoped engagement, not a claim about any particular customer's configuration. Replace every generic object with a named test account, record, workspace, role or application that your team owns. The expected behavior should be approved by the business owner before the tester observes it.

Figure 1: A practical evidence path for this assessment. The stages are an editorial test-planning model based on the cited provider documentation.

Build a trust-edge inventory before testing

GitHub explains that the OIDC token contains claims identifying the workflow and that the cloud provider evaluates those claims before issuing a short-lived token. GitHub Docs, OpenID Connect The buyer should collect each relevant workflow file, target cloud role, subject template, environment rules and cloud policy. Record who owns the role. A generic request to "check OIDC" misses the fact that one enterprise can have many trust edges with different owners.

Start with a controlled production-like role that has low-impact permissions and a synthetic resource. Test the intended workflow first. Then change one condition at a time using test repositories and refs owned by the customer. This lets the team distinguish a broadly written cloud trust policy from a failure in the workflow itself. Never test a third-party repository or attach a production deployment role to an unapproved workflow.

Read the cloud policy as an access decision

AWS IAM documentation warns that the GitHub sub condition must be limited to the specific organization or repository; otherwise workflows outside the intended boundary can assume the role. It also describes how AWS checks the subject condition during role setup. AWS IAM The assessment should record the actual condition keys and compare them with the subject of the intended job. A wildcard that still narrows to a repository is different from one that trusts any repository, so quote the exact policy before describing risk.

Subject customization can change claim composition. GitHub's OIDC reference documents available claims and customization options. GitHub Docs, OIDC reference The tester should inspect the organization's current template and the repository's opt-in status. A test based on a default subject format may be wrong if the organization customized it. Keep the observation in the report, not a copied token that remains useful to a reader.

Account for the 2026 subject format and environment behavior

GitHub changed the default sub format for repositories created after 15 July 2026: it now includes immutable owner and repository IDs. Older repositories retain the earlier name-based default unless they opt in; a rename or transfer after that date also moves to the immutable format. GitHub Enterprise Server is outside that rollout. GitHub Docs, Immutable subject claims A buyer should therefore inventory repository creation and migration state before copying a sample trust-policy string. A policy written for a legacy subject may stop deployments after a migration, while a broad policy written to avoid breakage may trust more workflows than intended.

The default subject also changes with job context. When a job references an environment, its default subject includes the environment name. The default subject includes a branch or tag only when the job does not reference an environment and is not a pull request job. GitHub Docs, Example subject claims That means the matrix's branch row is conditional. For an environment-bound production job, test the protected environment's approval and branch restrictions in GitHub, plus the cloud trust condition that matches the actual environment subject. Do not claim that a branch string is present in the default token when it is not.

A practical evidence packet contains one redacted claim set from an approved job, the repository's subject-format setting, the workflow's environment reference, the cloud role condition and the corresponding denied test. The tester should note whether the organization customized the subject and whether that customization includes an immutable repository identifier. GitHub says immutable owner and repo IDs remain in the subject for repositories using the immutable format, even when claims are customized. GitHub Docs, OIDC reference

If a buyer uses multiple cloud providers, repeat the mapping for each provider policy instead of assuming that one provider evaluates the same claims in the same way. The business decision is whether the right deployment workflow can reach the right role, and whether a sibling workflow, repository or environment is denied. This is a better acceptance test than simply observing that a deployment succeeded.

Translate the actual subject into test cases

Do not write a test from a sample policy before identifying the claim shape of the job in scope. GitHub's OIDC reference describes several default contexts. The following table is a decision aid; the symbolic owner and repository names are placeholders, not a policy to deploy.

The branch, tag and pull request forms are alternatives under the default format. An environment reference changes the subject context, so a cloud role restricted to environment:production cannot, by that default subject alone, distinguish two branches that are both allowed to reach that environment. GitHub's deployment environment documentation says deployment branches and tags can be restricted, and required reviewers can gate a job. A particularly useful procurement question is whether the production environment has an explicit branch rule. GitHub notes that selecting “protected branches only” permits all branches if no branch protection rules are defined. The test should inspect that setting, not infer protection from the environment's name.

For an environment-bound job, a safe negative case starts a controlled workflow from an unapproved branch against a test environment configured like the production environment. Record whether the job was blocked before any cloud token exchange. A second case uses an approved branch and verifies that the reviewer or other protection rule behaves as configured, then that the cloud role accepts the intended environment subject. A tester should not claim that AWS enforced a branch condition when GitHub's environment gate made the decision. Distinguishing where the denial occurred tells the right team what to fix and makes the retest repeatable.

Trace permission from workflow to cloud resource

GitHub requires id-token: write at the job or workflow level before a job can request an OIDC token. Its reference also says this permission alone does not grant write access to other resources. The cloud trust policy decides whether the token can be exchanged, and the resulting cloud role's permission policy decides what the job can do. These are separate controls that should appear on separate rows in the report. An assessment that checks only for id-token: write in workflow YAML cannot conclude that the deployment role is safe or unsafe.

For an AWS role, the buyer should ask for the exact OIDC provider, audience and sub condition, then the role's attached and inline permission policies. GitHub's AWS OIDC guide uses sts.amazonaws.com as the audience in its AWS trust examples and shows how a role is associated with a repository and job context. AWS separately warns that a subject condition not limited to the intended organization or repository can admit outside workflows. A positive exchange should identify the temporary role that was assumed. The resource test should then prove one permitted deployment action and one denied, low-impact action on a synthetic resource. The second result measures role privilege rather than OIDC matching.

Do not treat a wildcard as a single kind of finding. A pattern that covers approved release branches in one repository differs from a pattern that covers every branch, pull request and environment in that repository; a pattern that crosses repositories is broader again. GitHub's AWS guide shows that a repository-wide wildcard can admit all of those job contexts. The buyer should ask the tester to enumerate the workflows and refs the pattern matches today, identify which are approved to deploy, and run a controlled denied case for a context just outside the intended set. The finding should describe the observed excess scope, not label every wildcard equally dangerous.

Account for reusable workflows and changes of ownership

Many enterprises centralize deployment in a reusable workflow. GitHub documents a job_workflow_ref claim that identifies the called workflow while the ordinary workflow, ref and repository claims describe the caller. GitHub, OIDC with reusable workflows A cloud policy that trusts every caller in an organization because all callers use the same deployment template may be broader than the business intended. The assessment should record both sides: which caller repositories are authorized to invoke the deployment workflow and which called workflow revision the policy is meant to trust. Where the provider supports custom claims or a customized subject, ask the platform owner whether job_workflow_ref is part of the enforced condition. Do not assume AWS, Azure and Google Cloud evaluate it in the same way.

The change review should include repository rename, transfer, template migration and workflow retirement. In the current GitHub format, an immutable subject includes owner and repository IDs; older repositories may still emit name-based subjects unless migrated. GitHub, OIDC reference Before a rollout, record the existing subject, the new subject the approved job will emit, every cloud policy that consumes it, and the owner who can change each policy. After rollout, demonstrate an approved exchange and inspect the cloud policy to prove the retired condition was removed. If a customer-owned legacy-format job can still present the old subject, add a controlled denied case. Keeping an obsolete broad condition alongside the new precise one preserves a trust edge the migration was supposed to close. The final inventory should name both the job owner and the cloud role owner so the next transfer triggers the right review.

Check the role after trust succeeds

A role restricted to the right workflow can still have excessive cloud privileges. Choose a permitted deployment action and a denied action against a synthetic resource in another project or account. Record the temporary role identity, cloud policy and observed result. This makes the assessment about business consequence, not only policy syntax.

A robust deliverable is a table of workflow, subject, audience, cloud role, allowed resources, test result and owner. Separate confirmed failure, design concern and not tested. Include a retest of any changed condition. A test of one workflow does not validate every runner, dependency or artifact path in the pipeline; those need their own scope. The existing CI/CD pipeline scope guide covers the broader build chain.

Define what an accepted GitHub OIDC test proves

An enterprise buyer can make the SOW testable by naming a workflow job, the repository that owns it, the event and ref that start it, the environment it references, the token audience, the cloud role, and the resource that role should reach. Record the actual sub format rather than a copied example. The expected decision should be written for each job-to-role edge before the tester runs it: “this approved job may assume the deployment role” and “this controlled sibling context may not.” The same job may deploy to more than one cloud account, so each trust policy needs its own row and owner.

At minimum, ask for a successful exchange from an approved job and a denial from a customer-owned repository or job outside its scope. Where the subject includes a branch or tag, test an adjacent unapproved ref. Where it includes an environment instead, test the environment's branch or tag restriction and approval behavior before asking whether the cloud accepts the environment subject. Add a wrong-audience case using a controlled test role, then separately test whether the accepted role can perform one necessary operation and is denied a neighboring operation on synthetic resources. Each negative case identifies a different boundary; one failed deployment cannot stand in for all of them.

The report should preserve a redacted claim set, the workflow and run reference, the cloud trust condition, the resulting role identity or denial, and the permitted or forbidden resource action. It should identify whether GitHub blocked the job, the cloud rejected the OIDC exchange, or the role lacked a resource permission. A denial at GitHub's environment gate is positive evidence for that gate, but says nothing about whether a second workflow could satisfy an overbroad cloud policy. A cloud denial from a malformed test token is not evidence that the intended trust is narrow. Test the positive path first and keep the claim values needed to explain each decision, without delivering a live JWT or temporary cloud credential.

Retest the precise control changed. If the cloud sub pattern is narrowed, repeat the approved job and the previously admitted denied context. If environment branch protection changes, repeat the controlled branch attempt and approval flow, then confirm the intended deployment still runs. If role permissions change, repeat both the permitted and forbidden resource operations. If immutable subjects are adopted, capture the new subject, show that the accepted job still assumes the role, and inspect all old policies for obsolete name-only conditions. The final result should distinguish a confirmed runtime failure, a policy exposure inferred from configuration, and an untested path.

Questions to put in a GitHub-to-cloud RFP

Ask the testing provider how it will identify repositories using the newer immutable subject format and older repositories that have not opted in. Will it inspect organization customization and each repository's effective subject, including reusable workflows? Which GitHub environments have branch, tag or reviewer protection, and how will the tester verify those settings? GitHub's OIDC reference and deployment environment guide provide the source definitions; the customer's own configuration supplies the answer. A provider who proposes a single static sub example for an entire enterprise has not yet scoped its actual trust edges.

Ask for the cloud-side method as well. For AWS, will the provider inspect the role trust policy's issuer, audience and sub conditions separately from its permission policies? How will it show that a repository-wide wildcard covers only workflows the business intended to authorize? What is the safe test role, account and synthetic resource, and who owns each? If Azure or Google Cloud is also in scope, require a provider-specific claim mapping instead of assuming the AWS condition syntax carries over. A quote should state how many distinct job-to-role edges, cloud accounts and environments will be examined; otherwise the buyer cannot tell whether “GitHub OIDC testing” means one deployment or the release estate.

Finally, ask which connected surfaces are excluded and who can authorize them. A third-party action, external reusable workflow or provider-owned service may need its own terms and owner approval. Require the rules of engagement to name allowed workflows, test repositories, cloud roles, request budget, monitoring contacts, change window and stop condition. Require the final report to identify both the GitHub workflow owner and cloud role owner for each finding. That makes it possible to close the condition that actually failed, and to revisit the trust when a repository is transferred or a deployment workflow is retired.

What Stingrai can scope

Stingrai is a CREST-accredited penetration testing company with cloud testing that includes IAM trust relationships and CI/CD credential exposure. A human-led assessment here can follow a customer-owned GitHub job through OIDC claim issuance, cloud role trust and a narrowly authorized resource action. The SOW should name the workflows, repositories, environments, roles and test accounts that the customer controls. The report can distinguish an overbroad sub condition from an excessive cloud permission, attach evidence for each result, and retest the exact condition the owner changes.

A one-time test can answer whether a release migration or audit-scope deployment is properly bounded. A continuous program can revisit roles as repositories, environments and workflows change. The service overview describes Stingrai's one-time and ongoing testing models and its retest workflow. The buyer should require the chosen model's coverage to be explicit and use the resulting findings as evidence for its own security and audit process.

Frequently Asked Questions

What should a GitHub Actions OIDC pentest cover?

It should map selected workflows to cloud roles, test repository, ref, environment and audience conditions, and verify that an accepted workflow receives only the required cloud permissions.

Does using OIDC eliminate the need to test cloud role trust?

No. OIDC removes the need for a long-lived GitHub cloud secret, but the cloud role still needs conditions that restrict which workflow can exchange a token and what that role can access.

What does AWS require in a GitHub OIDC trust policy?

AWS checks for a GitHub subject condition that is present and not solely a wildcard. AWS also warns that a condition that does not limit the intended organization or repository can allow outside workflows to assume the role.

What evidence should be delivered?

Require the workflow-to-role inventory, relevant claims and policy conditions, controlled accepted and denied cases, effective cloud privileges, remediation owner and retest result.

Related reading

• Microsoft Entra Workload Identity Federation Test Plan

• Databricks Unity Catalog Security Test Matrix for Buyers

• CI/CD Pipeline Penetration Testing: What a Build-Chain Test Scopes That an App Pentest Misses

Talk to Stingrai

Share the assets, identities and expected access decisions you want tested. Get a Quote or book a free discovery call to define the authorization boundaries and deliverables.