Cloud identity demo alarm

OpenID Connect is the badge system many engineering teams use so GitHub Actions can get temporary Amazon Web Services credentials without storing long-lived keys. At SpecterOps’ SO-CON 2026 conference on April 13-14, a live demo showed that a bad trust rule can turn that safer design into immediate cloud access for code from a GitHub fork. (specterops.io) (docs.aws.amazon.com) In this setup, GitHub issues a signed JSON Web Token, and Amazon Web Services Security Token Service exchanges it for short-lived credentials tied to an Identity and Access Management role. Amazon Web Services says teams should use this flow instead of embedding long-term access keys in applications outside Amazon Web Services. (docs.aws.amazon.com) GitHub’s own setup guide says administrators need at least one condition in the role trust policy so untrusted repositories cannot request tokens for cloud resources. The guide specifically points teams to the `token.actions.githubusercontent.com:sub` claim, which can pin access to one repository, branch, or environment. (docs.github.com) Amazon Web Services’ security blog gives the same advice in plainer deployment terms: scope the trust relationship to the intended GitHub organization, repository, and branch, then assign minimum permissions to the role. That design assumes the trust policy is narrow enough that only the expected workflow can assume the role. (aws.amazon.com) The risk appears when that trust policy is broad, missing, or written loosely enough to match more workflows than intended. Datadog Security Labs reported in 2023, and updated in June 2025, that some Amazon Web Services roles on the internet lacked a subject-condition check entirely, which let unauthorized GitHub Actions assume them and retrieve credentials. (securitylabs.datadoghq.com) That cloud trust problem overlaps with a second GitHub Actions problem: forked pull requests. GitHub says `pull_request_target` runs in the base repository context and carries higher risk with forks because secrets can be exposed if untrusted code or input influences execution. (github.blog) GitHub changed `pull_request_target` behavior on December 8, 2025 so the workflow source always comes from the default branch, closing one class of edge cases. But GitHub also said the event still has “increased risk” with external forks and requires care to keep untrusted code from affecting privileged jobs. (github.blog) Security researchers have shown what that looks like in practice. Orca Security said in September 2025 that misconfigured `pull_request_target` workflows let attackers move from a forked pull request to code execution on GitHub runners, with paths to secret theft, token abuse, and changes to trusted branches. (orca.security) GitHub’s default protection is narrower than many developers realize: secrets are not exposed to workflows triggered from forks by default. Separate guidance for maintainers warns that checking out fork code inside a privileged workflow is insecure because it gives anyone who can open a pull request a path to whatever secrets or tokens that job can reach. (michaelheap.com) Put together, the lesson from the demo is simple: “keyless” does not mean “harmless.” If a GitHub workflow can mint a token and an Amazon Web Services role trusts the wrong subject, the missing secret is replaced by a temporary credential with exactly the permissions the role allows. (docs.github.com) (securitylabs.datadoghq.com)