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

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:

1. Uses OIDC for AWS authentication
2. Has the role ARN hardcoded in a public workflow file
3. 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:

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.