CKV_GCP_125: check too big, not documented, cumbersome to satisfy

[pndurette]

Describe the issue

CKV_GCP_125 has 8 possible failure cases with a very generic error ("Ensure GCP GitHub Actions OIDC trust policy is configured securely").

It just triggered for us on existing resources and it's very cumbersome to know what's up without any documentation. I have to go through the check source code line-by-line running the code in my head with my Terraform code next to it to try to see what it suddenly complains about.

Either it needs better explanation of what's being checked or it needs to be broken up in way more checks.

Examples N/A

Version (please complete the following information):

• Checkov Version 3.2.357 (from the GitHub Actions run log)

Additional context N/A

[issacg]

FWIW, this seems to have been introduced in https://github.com/bridgecrewio/checkov/pull/6964 The code used to be more verbose about the failure reason, and these printed reasons were prune from the code in the above PR. Perhaps this can be restored?

[dothomson]

I've also just encountered this issue.

Additionally the rule doesn't handle cases where the attribute condition is constructed using variables or locals.

I was providing the repo name via a module variable but will now have to disable to check as this rule is not specific and unclear on why it isn't working

[ethankent]

Thanks for digging into this - CKV_GCP_125 is an extremely valuable guard‑rail. A mis‑scoped workload‑identity trust policy can hand attackers the keys to an entire GCP project, so tightening this check closes a potentially gaping security hole.

While tracing the failure, I noticed the rule relies on a single regex:

claim_match = re.search(r"assertion\.sub\s*==\s*['\"]([^'\"]+)['\"]", condition)

That pattern matches only assertion.sub == "<literal>". Legitimate CEL such as

assertion.sub in ['repo:x', 'repo:y']

or macro forms ([].exists(...)), variables, and escaped quotes fall through and the rule surfaces a generic failure. Each new edge case added via another regex feels brittle and risks making the check noisy enough that teams disable it - the opposite of what we want.

Suggestion

Consider switching from regex matching to a lightweight CEL parser (e.g., a thin wrapper around cel‑python or a purpose‑built tokenizer). A parser would:

1. Handle list membership, variables, and future CEL features without ongoing regex churn.
2. Produce clearer, more actionable error messages.
3. Keep the rule wieldy (low‑noise and high‑signal) so it remains enabled rather than suppressed.

Appreciate the hard work on Checkov; strengthening this rule will go a long way toward keeping real‑world pipelines secure.

[adam-homeboost]

As another example of this, I was provided this by a vendor in order to automate an integration with them. The current check favors Github integration issues and until very recently the error message for this check mentioned github when it wasn't even involved. This case does not involve github in any way even though the documentation for addressing this only talks about github relevant tokens.

This snippet is from a security scanning vendor in fact. It is unclear from the documentation how to address this and it may in fact be a false positive (the vendor who provided us this configuration considers it a false positive):

resource "google_iam_workload_identity_pool_provider" "vanta_identity_provider" {
  project                            = google_project.example.project_id
  workload_identity_pool_id          = google_iam_workload_identity_pool.example_pool.workload_identity_pool_id
  workload_identity_pool_provider_id = local.identity_provider_id
  display_name                       = "Example AWS"

  attribute_mapping = {
    "google.subject" = "'${local.subject_name}'"
    "attribute.arn"  = "assertion.arn"
  }
  attribute_condition = "attribute.arn.extract('assumed-role/{role}/') == '${local.aws_role_name}'"
  aws {
    account_id = "12345678910"
  }
}

Where local vars identity_provider_id, subject_name and aws_role_name are simple string values.

[mw-root]

I just ran into the above case as well, I'm building an AWS provider and getting errors based on GitHub Actions