In April 2021, attackers who breached Codecov's Bash Uploader script spent roughly two months quietly harvesting environment variables from thousands of customer CI pipelines — including long-lived AWS access keys that had been sitting untouched in build configs for months or years. Static keys like those don't expire on their own, so once they leak, they stay valid until someone notices and manually revokes them. That is exactly the gap AWS STS temporary credentials are built to close. Instead of a 20-character access key ID and secret that work forever, AWS Security Token Service issues short-lived credentials — often valid for as little as 15 minutes to 12 hours — that expire automatically whether or not anyone catches the leak. For teams securing software supply chains, that difference between "forever" and "one hour" is often the difference between a contained incident and a headline breach.
Why Are Long-Lived AWS Access Keys So Risky?
Long-lived AWS access keys are risky because they remain valid indefinitely, giving attackers an unbounded window to find and exploit them. A key generated for a CI job in 2022 and never rotated is just as usable by an attacker in 2026 as it was the day it was created — AWS itself has no mechanism to force it to expire. That durability is precisely why static keys show up so often in breach retrospectives. In the 2019 Capital One incident, a misconfigured web application firewall let an attacker query the EC2 instance metadata service and pull temporary credentials tied to an over-permissioned IAM role, ultimately exposing data on over 100 million customers. The credentials in that case were technically temporary, but the underlying lesson generalizes: any credential — long-lived or short-lived — that is scoped too broadly or exposed too easily becomes a liability. Static keys simply remove the one safety net (automatic expiration) that limits how long that liability persists. GitGuardian's annual State of Secrets Sprawl reports have consistently found hundreds of thousands of AWS keys committed to public GitHub repositories every year, and once a key is public, automated scanners typically find and attempt to use it within minutes.
What Are AWS STS Temporary Credentials?
AWS STS temporary credentials are short-lived access key ID, secret access key, and session token triples issued by AWS Security Token Service that automatically expire after a configured duration. Unlike the permanent keys attached to an IAM user, temporary security credentials AWS issues through STS are generated on demand — via AssumeRole, GetSessionToken, GetFederationToken, or AssumeRoleWithWebIdentity — and are scoped to a session rather than to an identity that persists forever. Because the session token expires, a credential set stolen from a compromised laptop, a leaked CI log, or an exposed .env file becomes worthless once the clock runs out, even if the underlying breach is never detected. Default expiration windows vary by call: AssumeRole sessions default to one hour and can be configured up to 12 hours, while federated sessions via GetFederationToken can run up to 36 hours. This is also why AWS bakes STS into so much of its own architecture — EC2 instance roles, Lambda execution roles, and ECS task roles all hand workloads temporary security credentials AWS rotates automatically behind the scenes, so no developer ever has to hardcode a key into an application at all.
How Does STS AssumeRole Work Under the Hood?
STS AssumeRole works by exchanging an existing identity's trust for a fresh, time-boxed set of credentials scoped to a specific IAM role. A caller — a user, an application, or another AWS account — sends a request to sts:AssumeRole naming the target role's ARN. STS checks the role's trust policy to confirm the caller is permitted to assume it, then returns temporary credentials that carry only the permissions attached to that role, not the permissions of the original caller. This is the mechanism behind cross-account access, federated single sign-on, and Kubernetes workloads using IAM Roles for Service Accounts (IRSA). Good STS AssumeRole security also depends on the conditions attached to the trust policy: requiring an external ID for third-party access (a control AWS has recommended since at least 2015 to prevent confused-deputy attacks), enforcing multi-factor authentication for sensitive roles via aws:MultiFactorAuthPresent, and restricting source IP ranges or VPC endpoints all shrink the pool of callers who can ever request a session in the first place. Skipping these conditions doesn't break AssumeRole functionally, but it does mean a compromised low-privilege identity can potentially assume its way into a high-privilege role with nothing more than a single API call.
What Are the Assume Role Best Practices Every Team Should Follow?
The core assume role best practices are: scope trust policies tightly, set the shortest workable session duration, require external IDs and MFA for sensitive roles, and never let a role's permissions exceed what its intended callers actually need. In practice, that means auditing sts:AssumeRole trust relationships the same way you'd audit IAM policies — a role that any authenticated principal in an account can assume is functionally equivalent to a shared credential. AWS's own Well-Architected Framework recommends setting MaxSessionDuration to the lowest value a workflow can tolerate rather than defaulting to the 12-hour ceiling, since a 12-hour token stolen mid-session gives an attacker 12 hours of usable access instead of one. Teams should also tag and log every assumed-role session through CloudTrail, since STS activity is logged under the assumed role's session name, which makes it possible to trace an action back to the original caller during an investigation — something that's much harder to do with a shared static key used by five different CI jobs. Finally, avoid nesting long-lived credentials underneath temporary ones: an IAM user's static key used solely to call AssumeRole still needs to be rotated and monitored, so many mature teams replace even that outer key with OIDC federation from GitHub Actions, GitLab CI, or another identity provider, eliminating standing AWS credentials from the pipeline entirely.
How Long Should Temporary Security Credentials Actually Last?
Temporary security credentials AWS issues should last only as long as the task genuinely requires, which in practice means minutes to a few hours for most automated workloads. A CI pipeline that builds and pushes a container image typically needs credentials for well under 15 minutes, so there's little reason to configure a session that lasts 12 hours "just in case." Shorter sessions matter because they cap the damage of two failure modes at once: a credential that leaks mid-job and a credential that outlives the job it was issued for because a process hung or a container was never cleaned up. AWS Lambda takes this to its logical conclusion — execution role credentials are refreshed automatically roughly every hour for the life of the function, so a workload never holds a session token long enough for manual rotation to even be a meaningful concept. Organizations moving toward zero standing privilege take the same principle further, provisioning STS sessions only at the moment of use through just-in-time access requests rather than keeping any role continuously assumable, so that even the ability to request credentials is time-boxed and auditable.
How Safeguard Helps
Safeguard treats credential hygiene as a core software supply chain security control, not an afterthought bolted onto IAM. Our platform continuously scans source repositories, CI/CD pipeline configurations, container images, and build artifacts for exposed static AWS access keys — the exact class of long-lived secret that turned the Codecov compromise into a multi-month exposure window — and flags them before they reach production or a public repository. Beyond detection, Safeguard maps IAM roles and trust policies across your AWS accounts to surface overly permissive sts:AssumeRole relationships, missing external ID conditions, and session durations set far longer than a workload's actual runtime, so your team can apply assume role best practices consistently instead of role by role. For pipelines still relying on standing credentials, Safeguard identifies which jobs are candidates for OIDC-based federation and highlights where AWS STS temporary credentials could replace a static key outright. And because software supply chain attacks increasingly target the CI layer specifically to harvest exactly these kinds of secrets, Safeguard correlates credential exposure findings with build provenance and dependency risk, giving security teams one place to see not just that a key leaked, but how it could have been used and what it could reach. The result is fewer standing credentials in your environment, tighter blast radius when something does go wrong, and an audit trail that shows regulators and customers alike that temporary, least-privilege access is the default — not the exception.