A CI role is worth flagging when it has wildcard actions or resources, a trust policy anyone in your repository can use, an unscoped PassRole, no conditions, or an access key that never rotates. This checklist walks through each flag and what to do about it.
The checklist
Open the role's trust policy and permissions policy side by side. Score each line.
| Flag | Why it matters | Fix |
|---|---|---|
| Action set to a star | Role can do anything in the service or account | List the actions used |
| Resource set to a star | Actions apply to every resource | Name ARNs or prefixes |
| PassRole on a star resource | Can attach any role to a service | Scope to named roles |
| Trust policy with a repository wildcard | Any branch, pull request or environment can assume it | Exact match on the subject |
| No audience condition | Tokens for other audiences may be accepted | Require the expected audience |
| Long session maximum | Stolen credentials live longer | Match the longest job |
| IAM user access key in CI secrets | Long term credential, rotated by hand | Move to OIDC federation |
| Role used by many pipelines | One compromise reaches all of them | One role per purpose |
Trust side flags
The trust policy decides who can become the role. For GitHub Actions federation with AWS, GitHub's guide says you must define at least one condition so untrusted repositories cannot request access tokens, and shows that a pattern ending in a repository wildcard allows any branch, pull request merge branch or environment in that repository.
For GitLab, the documentation recommends including stable identifiers such as the project ID alongside the subject, since the project ID stays the same for the project's lifetime, and cautions against using a user login or email as the only condition because users can change them.
If your trust policy would accept a token minted by a fork or an unreviewed branch, that is the first thing to fix.
Permission side flags
AWS's best practices page asks for least privilege: define the actions on specific resources under specific conditions. It also says AWS managed policies may not grant least privilege for your use case because they are written for all customers, so move to customer managed policies tailored to the job.
Common CI patterns that deserve a look:
- A deploy role with full administrative access "to make the pipeline work".
- Read and write on every storage bucket when the job writes to one.
- Permission to create or edit IAM roles and policies, which lets the role grant itself more.
- A role shared by test, staging and production jobs.
Evidence flags
Ask whether you can show what the role did. CloudTrail records STS and IAM calls, including web identity role assumptions, so a role with no trail in its account is a blind spot. A role nobody has reviewed in a year is another soft flag. AWS recommends regularly reviewing and removing unused roles, permissions and credentials using last accessed information.
How to run the ten minutes
- Minutes 1 to 3: read the trust policy and mark every wildcard.
- Minutes 4 to 6: read the permissions and mark star actions, star resources and PassRole.
- Minutes 7 to 8: check session duration and whether any long term keys still exist for this pipeline.
- Minutes 9 to 10: write the top two fixes as tickets, and pick an owner.
Do not try to fix everything at once. Removing one wildcard from trust and one from permissions beats a perfect plan that ships next quarter.
Quick check
Is an AWS managed policy fine for a CI role?
It is a reasonable starting point, but AWS says managed policies may not give least privilege for your case. Tighten them with a customer managed policy.
What is the single most urgent flag?
A trust policy that lets untrusted code assume the role. Fix who can become the role before you fix what it can do.
Safeguard does not manage your cloud accounts. It scans your code and dependencies, applies pull request policies and gates, and automates compliance evidence. A free scan is available at gold.safeguard.sh/scan.
Sources
- AWS IAM User Guide: Security best practices in IAM
- GitHub Docs: OIDC in Amazon Web Services
- GitLab Docs: ID token authentication
Last reviewed: 19 October 2026.
