DEV Community: TrustFix

January 2026 AWS Condition Keys: What Changed and Why It Matters

TrustFix — Thu, 09 Apr 2026 15:00:00 +0000

In January 2026, AWS added new condition context keys for GitHub Actions OIDC trust policies. This was a quiet update — no blog post, no re:Invent announcement — but it fundamentally changes how you should write trust policies for GitHub Actions federation.

The problem: mutable identifiers

Before January 2026, the standard way to restrict an OIDC trust policy to a specific GitHub repository was to use the sub claim with the repository name:

{
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
    }
  }
}

The problem: my-org/my-repo is a mutable identifier. If someone renames the repository, transfers it to another organization, or deletes and recreates it with the same name, the trust policy still matches. The identity the policy was written for no longer exists, but something with the same name does.

This isn't theoretical. GitHub repository transfers happen routinely during acquisitions, reorganizations, and open-source project migrations.

The fix: immutable condition keys

AWS now supports these condition context keys for GitHub's OIDC provider:

repository_id — The immutable numeric ID of the repository. Survives renames and transfers.
actor_id — The immutable numeric ID of the GitHub user who triggered the workflow.
repository_owner_id — The immutable numeric ID of the organization or user who owns the repository.
runner_environment — Whether the workflow is running on GitHub-hosted or self-hosted runners.

These are part of the OIDC token claims that GitHub sends to AWS. They've always been in the token — AWS just didn't allow you to use them in trust policy conditions until January 2026.

How to update your trust policies

Before (mutable):

condition {
  test     = "StringEquals"
  variable = "token.actions.githubusercontent.com:sub"
  values   = ["repo:my-org/my-repo:ref:refs/heads/main"]
}

After (immutable):

condition {
  test     = "StringEquals"
  variable = "token.actions.githubusercontent.com:sub"
  values   = ["repo:my-org/my-repo:environment:production"]
}

condition {
  test     = "StringEquals"
  variable = "token.actions.githubusercontent.com:repository_id"
  values   = ["123456789"]
}

condition {
  test     = "StringEquals"
  variable = "token.actions.githubusercontent.com:repository_owner_id"
  values   = ["987654321"]
}

The repository_id is a belt-and-suspenders approach alongside the sub claim. Even if the repository name changes, the immutable ID check will either still match (same repo, renamed) or fail (different repo with the same name).

Finding your repository_id

Your repository's immutable ID is available via the GitHub API:

curl -s https://api.github.com/repos/my-org/my-repo | jq .id

Or in any GitHub Actions workflow, it's available as github.repository_id.

What our scan found

In our 10,000-repo scan, we analyzed how repositories reference their identity in OIDC trust policies. The vast majority still use mutable repository names. Adoption of the January 2026 immutable keys is near zero in public repositories — the feature is too new and there's been minimal documentation from AWS about the change.

This creates a temporal window: teams that adopt these keys now have a meaningful security advantage over those who haven't heard about the update.

What to do today

Add repository_id conditions to all OIDC trust policies alongside your existing sub conditions
Add repository_owner_id to prevent cross-organization confusion
Use StringEquals (not StringLike) for all condition comparisons
Add an environment condition for production-critical roles

TrustFix detects trust policies that are missing immutable condition keys and generates the Terraform fix automatically. Try it at trustfix.dev.

The condition keys referenced in this post are documented in AWS's OIDC federation documentation.

Originally published at trustfix.dev. TrustFix is a non-human identity security platform that detects trust policy misconfigurations and auto-generates validated Terraform fixes. Free CLI: npx oidc-audit scan.

Checkov's OIDC Bug: Why CKV_AWS_358 Misses 80% of Misconfigurations

TrustFix — Tue, 07 Apr 2026 15:00:00 +0000

If you're using Checkov to audit your AWS IAM OIDC trust policies, you might assume you're covered. Checkov is an excellent general-purpose infrastructure-as-code scanner with hundreds of built-in checks — it's one of the best tools in the IaC security space and I use it myself. But OIDC trust policies are a specialized domain, and Checkov's coverage there has a gap.

It's not. Checkov has exactly one OIDC-related check — CKV_AWS_358 — and it has a confirmed bug that causes false positives on non-OIDC roles.

The bug: sts:AssumeRole vs sts:AssumeRoleWithWebIdentity

CKV_AWS_358 is supposed to detect IAM roles that allow OIDC federation without proper condition restrictions. The check looks for trust policies that permit assuming the role via web identity federation.

The problem is on line 65 of the check: it searches for sts:AssumeRole in the trust policy action field. But OIDC federation uses sts:AssumeRoleWithWebIdentity — a different IAM action.

Because sts:AssumeRole is a substring of sts:AssumeRoleWithWebIdentity, the check matches both. This means any role that allows cross-account assume role (a completely normal pattern that has nothing to do with OIDC) gets flagged as an OIDC misconfiguration.

The result: noisy false positives that teach teams to ignore the check entirely.

This is the kind of subtle issue that's easy to miss in a scanner with 1,000+ checks — it doesn't reflect on Checkov's overall quality, just on the difficulty of getting OIDC-specific detection right.

Even without the bug: 1 check out of 10 patterns

Let's assume the bug gets fixed. CKV_AWS_358 checks for one thing: whether an OIDC trust policy has conditions restricting which identities can assume the role.

That's one misconfiguration pattern out of at least ten that matter:

#	Misconfiguration	CKV_AWS_358	TrustFix
1	Missing sub condition	Partial (buggy)	Yes
2	Overly broad trust (StringLike wildcards)	No	Yes
3	Missing audience condition	No	Yes
4	Fork PR risk (hardcoded ARN + PR trigger)	No	Yes
5	Wildcard environment	No	Yes
6	Expired OIDC provider	No	Yes
7	Overprivileged role permissions	No	Yes
8	Overprivileged admin role	No	Yes
9	AI agent overprivileged role	No	Yes
10	AI agent missing scope condition	No	Yes

Patterns 2 through 10 are invisible to Checkov.

1 of 5 OIDC providers

CKV_AWS_358 checks for GitHub's OIDC provider (token.actions.githubusercontent.com). But AWS IAM supports OIDC federation with at least five major CI/CD providers:

GitHub Actions — token.actions.githubusercontent.com
GitLab CI — gitlab.com
Terraform Cloud — app.terraform.io
CircleCI — oidc.circleci.com
Buildkite — agent.buildkite.com

Checkov only checks GitHub. If your organization uses GitLab CI with AWS OIDC federation and has a misconfigured trust policy, Checkov will never flag it.

Trivy: zero OIDC checks

For completeness: Trivy, another widely-used security scanner, has zero AWS OIDC trust policy checks as of April 2026. It's excellent for container image scanning and Kubernetes misconfiguration detection, but OIDC trust policies are outside its current scope.

The fix generation gap

Even if Checkov's detection were comprehensive, it stops at detection. It tells you something is wrong but doesn't tell you exactly how to fix it.

For OIDC trust policies, the fix is nuanced. You need to know:

Which condition key to use (sub vs repository_id vs actor_id)
Whether to use StringEquals or StringLike
What the correct condition value format is for your specific repository and branch
Whether to add an environment condition
How to handle the January 2026 immutable condition keys

TrustFix generates the exact Terraform code for the fix, validated through six layers of analysis, and opens it as a PR with a Confidence Score.

What this means

If OIDC trust policy security is important to your organization (and given that 743 repos are critically vulnerable per our 10,000-repo scan, it should be), don't rely on a single buggy check in a general-purpose scanner.

Dedicated tooling exists. TrustFix covers all 10 patterns across multiple OIDC providers and generates validated fixes. Free tier available — 1 AWS account, unlimited scanning.

Disclosure: I built TrustFix. The Checkov bug referenced here is publicly documented in GitHub issue #6983. I have immense respect for the Bridgecrew/Palo Alto team and the open-source security community. This post is about a gap in OIDC-specific coverage, not a critique of Checkov's broader capabilities.

80% of GitHub Repos Still Use Static AWS Credentials in 2026

TrustFix — Sun, 05 Apr 2026 15:00:00 +0000

We scanned 10,000 public GitHub repositories and analyzed 54,767 GitHub Actions workflows that interact with AWS. The goal was simple: understand how the industry is handling the transition from static AWS credentials to OIDC-based authentication in CI/CD pipelines.

The results are worse than we expected.

The headline numbers

Out of 54,767 workflows analyzed across 10,000 repositories:

80.7% still use static AWS credentials (AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY stored as GitHub Secrets)
19.2% have adopted OIDC federation via configure-aws-credentials
7.6% have hardcoded IAM role ARNs directly in public workflow files
Only 13.9% use GitHub environment protection rules
743 repositories are critically vulnerable — they have hardcoded role ARNs AND accept pull_request triggers, making them exploitable via fork-based OIDC token theft

To put that in context: if you open a pull request against any of those 743 repos, the workflow runs with the base repository's OIDC trust — potentially giving you access to their AWS account.

OIDC adoption is growing, but slowly

GitHub Actions added OIDC support in late 2021. AWS followed with configure-aws-credentials v2. The security benefits are clear: no long-lived secrets, automatic credential rotation, and fine-grained trust policies tied to specific repositories and branches.

Despite being available for over four years, OIDC adoption across the repositories we scanned sits at roughly a third. The remaining two-thirds rely on static credentials that, if leaked, provide persistent access until manually rotated. Based on workflow creation dates and commit timestamps in our dataset, adoption has been accelerating — but not fast enough.

The CRITICAL finding: 743 repos vulnerable to fork-based token theft

This is the most concerning pattern we found. When a repository:

Uses OIDC for AWS authentication
Has the role ARN hardcoded in a public workflow file
Accepts pull_request as a workflow trigger

...then anyone who forks the repo and opens a PR can potentially trigger a workflow that assumes the target's AWS IAM role. The attacker doesn't need the role ARN to be secret — it's right there in the YAML file.

Named repositories in this CRITICAL category include workflow files from pytorch/pytorch, botpress/botpress, redpanda-data/redpanda, great-expectations/great_expectations, aws/karpenter-provider-aws, h2oai/h2o-llmstudio, webiny/webiny-js, cloudquery/cloudquery, and supabase/supabase.

Yes, you read that correctly. AWS's own karpenter-provider-aws repository has a workflow in this pattern.

A note on responsible disclosure: All data in this report comes from publicly accessible GitHub repositories analyzed via the GitHub API. We follow responsible disclosure practices and standard 90-day timelines. Organizations mentioned above can contact security@trustfix.dev to discuss findings, request additional details, or be excluded from future publications. Our goal is to improve the ecosystem, not to shame individual projects.

How role ARNs are exposed

We categorized how repositories reference their AWS role ARNs:

Method	% of Workflows
Not visible (secrets/OIDC)	80.1%
GitHub Secrets reference	9.5%
Hardcoded in YAML	7.6%
Environment variable	2.8%

The 7.6% with hardcoded ARNs — that's 4,163 workflows across thousands of repositories with their AWS account ID and IAM role name sitting in plain text in a public GitHub repository. Combined with a pull_request trigger, this is an open door.

Environment protection: the forgotten control

GitHub Environments provide a critical security boundary: they require approval before a workflow can access environment secrets, and they restrict the OIDC sub claim to specific branches. This means even if someone opens a malicious PR, the workflow can't assume a role that requires the production environment unless an approver explicitly allows it.

Only 13.9% of the workflows we scanned reference a GitHub environment. The other 86.1% have no approval gate between a pull request and AWS credential access.

What this means for your team

If you're using GitHub Actions with AWS, here's what to check:

If you're still on static credentials: You're in the 80.7% majority, but that's not a good place to be. Every secret stored in GitHub is a credential that can be leaked via workflow logs, compromised actions, or repository access changes. Migrate to OIDC — it takes about 15 minutes per repository.

If you've adopted OIDC: Good start, but check your trust policy conditions. Use StringEquals (not StringLike) for the sub claim. Scope to specific repos AND branches. Use the immutable repository_id condition key that AWS added in January 2026 instead of the mutable repository name. Add an environment condition.

If you have hardcoded role ARNs: Move them to GitHub Secrets immediately. A hardcoded ARN in a public workflow file tells an attacker exactly which AWS account and role to target.

If you use pull_request triggers with OIDC: This is the most dangerous combination. Switch to pull_request_target with explicit checkout controls, or require environment approval before any AWS access in PR workflows.

Methodology

We used the GitHub Search API to find repositories containing configure-aws-credentials in their .github/workflows/ directory. For each repository, we fetched all workflow YAML files and analyzed them for credential patterns, OIDC configuration, role ARN exposure, trigger types, and environment usage. The scan covered 10,000 unique repositories across all languages and star counts. All data is from publicly accessible GitHub repositories.

The full dataset

We're publishing the complete statistical breakdown as part of our upcoming "State of OIDC Security 2026" report. If you want early access or have questions about the methodology, reach out at security@trustfix.dev.

You can scan your own AWS account for OIDC trust policy misconfigurations at trustfix.dev — free for the first AWS account, no credit card required.

This research was conducted by TrustFix as part of the State of OIDC Security 2026 initiative. All data is from publicly accessible GitHub repositories analyzed via the GitHub API.