Static long-lived cloud credentials instead of OIDC
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A cloud-auth action is configured with a static long-lived key (an AWS access key id, a GCP service-account JSON, or an Azure client secret) rather than short-lived OIDC federation. Long-lived keys sit in your secrets indefinitely and are the highest-value target if any secret leaks.
Why it matters
Configuring a cloud-auth action with a static access key or service-account credential means a long-lived, high-value secret sits in your repository secrets indefinitely. It does not rotate on its own, it works from anywhere, and it is the single most damaging thing to lose if any secret leaks. OIDC federation issues a short-lived token per run instead.
How to fix it
Switch to OIDC. Add id-token: write to the job permissions, register an identity provider and a role or workload-identity binding in the cloud, and configure the auth action with role-to-assume (AWS), workload_identity_provider (GCP), or an OIDC-based Azure login instead of a static key. Then delete the static credentials from your secrets.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo