fix(terraform): CKV_AZURE_249 should flag pull_request OIDC subjects

[Dashtid]

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Description

CKV_AZURE_249 currently passes a federated identity credential whose subject is repo:<org>/<repo>:pull_request.

That subject matches tokens minted by pull_request-triggered workflow runs — runs that execute a proposed change rather than the protected default branch. GitHub's security-hardening guidance treats the pull_request subject as a distinct, broader trust surface for exactly this reason: the code that runs during a pull request has not necessarily been reviewed or merged, and on public repositories it can originate from a fork.

Since an Azure FIC subject is an exact string match, a credential written this way trusts every pull-request run of that repository. The check inspects the subject closely enough to reject wildcards and abusable leading claims, so this seemed like a gap in the same family rather than an intentional allowance.

Change

One additional comparison in scan_resource_conf, after the existing repo-format check:

# Fourth check -> pull_request event
if (
    split_condition[0] == "repo"
    and len(split_condition) > 2
    and split_condition[2] == self.GH_PULL_REQUEST_EVENT
):
    return CheckResult.FAILED

It matches only the event segment (index 2) of a repo: subject, so it is deliberately narrow:

Subject	Before	After
repo:myOrg/myRepo:pull_request	PASSED	FAILED
repo:myOrg/myRepo:environment:pull_request	PASSED	PASSED (environment named pull_request)
repo:myOrg/pull_request:ref:refs/heads/x	PASSED	PASSED (repo named pull_request)
repo:myOrg/myRepo:ref:refs/heads/main	PASSED	PASSED
repo:myOrg/myRepo:environment:Production	PASSED	PASSED
repo:*, *, workflow:...	FAILED	FAILED

No other check or shared helper is touched, so CKV_AWS_358 / CKV_AWS_393 / CKV_GCP_125 are unaffected (their suites pass unchanged).

Tests

Two fixtures: fail_pull_request (the flagged subject) and pass_environment_named_pull_request, which pins the precision boundary so a later broadened match would fail the suite.

References:

• GitHub — security hardening with OpenID Connect (subject claim / pull_request): https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
• Microsoft Entra — workload identity federation considerations (FIC subject is an exact match): https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-considerations

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my feature, policy, or fix is effective and works
• New and existing tests pass locally with my changes

---

Two things I noticed while working in this file and left alone, in case they are of interest:

1. validate_subject_claim appears to be unused — scan_resource_conf re-implements the same sequence inline, and I could not find a caller. I mirrored the new condition into both so they do not drift further, but would removing it (or having scan_resource_conf call it) be preferable?

2. The check registers only azuread_application_federated_identity_credential. The AzureAD provider added azuread_application_flexible_federated_identity_credential in 3.7, where matching moves to a claims_matching_expression and the matches operator honours * — so claims['sub'] matches 'repo:org/*' there really does admit the whole org, unlike a classic FIC subject where * is an inert literal. Is flexible FIC out of scope by design, or would a follow-up covering that resource be welcome?

---

Note on overlap: #7610 (immutable OIDC subject IDs) adds a fixture to the same two Azure test files, so whichever of the two lands first will leave the other with a small fixture-level conflict. The changes are independent — that one widens gh_repo_regex, this one adds an event-segment comparison — and I am happy to rebase whichever comes second.

[Dashtid]

start-security-scan on this PR is now showing as failed rather than pending. The job is the one-line echo step in .github/workflows/security.yml whose only gate is environment: scan-security, and run 30527901430 sat awaiting that approval from 30 July until it hit Actions' 720-hour ceiling on 29 August. Nothing executed — the red X is the approval window expiring, not a test result.

It doesn't appear specific to this branch: the same 720h0m1s signature is on the other open fork PRs opened before late July (#7615, #7619, #7625 and #7628 among them), while fork PRs opened in the last few weeks still show it pending. The net effect is that external PRs turn from pending to failing at the 30-day mark without anything having run.

The branch is unchanged since it was opened and still merges cleanly. Happy to push a rebase if re-queuing is the easier path — or would approving the existing run in place be preferable, given a fresh run would start the same 30-day clock over?