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

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:

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:

1. GitHub Actions — token.actions.githubusercontent.com
2. GitLab CI — gitlab.com
3. Terraform Cloud — app.terraform.io
4. CircleCI — oidc.circleci.com
5. 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.