IAM condition key namespaced to the wrong issuer

Severity: medium on AWS, low on GCP and Azure.

What it means

Two situations, both of which a tool that only looked for "open" and "closed" would report wrongly.

AWS: the condition is namespaced to the wrong issuer

An OIDC condition key is prefixed with the provider's issuer:

token.actions.githubusercontent.com:sub

If the provider is GitHub but the condition says gitlab.com:sub, AWS never puts that key in the request context. A plain StringEquals on a missing key evaluates false, so the statement matches nobody.

That is a broken door, not an open one. Reporting it as wide open would be a false alarm of the worst kind. Reporting it as locked down would hide an outage waiting to happen: nobody can assume the role, and whoever eventually debugs that may reach for a wildcard to make it work.

The exception is ...IfExists operators, which pass vacuously when the key is absent. frontdoor checks for those and reports the door as genuinely open.

GCP and Azure: the expression could not be read

A GCP attributeCondition is CEL; an Azure federated credential can carry a claims-matching expression. frontdoor recognises the common forms and says what it could not read rather than guessing in either direction. The severity is low because this is a gap in the tool, not a proven weakness — and the raw expression is always in the finding so you can check it yourself.

How to fix it

AWS: rename the condition key so its prefix matches the provider URL exactly, without the scheme.

GCP / Azure: read the expression. A condition that constrains only aud, or only a timestamp, does not say who is calling. If the expression is correct and we failed to read it, please report it — that is a bug in the parser.