How to Prevent Hardcoded AWS Keys With Secret Scanning and IAM Roles

Retrospective: this article looks back at events from November 2017, written in 2026 with the benefit of hindsight.

Long-lived AWS access keys in source code have caused breaches at companies of every size, from Uber in 2016 to the extortion campaigns of the 2020s. Here is how to stop hardcoded keys from reaching your repositories — and remove the need for them.

Step 1: Turn on secret scanning

• Enable GitHub secret scanning and push protection (or the equivalent in GitLab or Azure DevOps). Push protection blocks commits that contain recognized credentials, including AWS access keys.
• Add a pre-commit hook such as gitleaks or detect-secrets for developer machines.

Step 2: Find what is already there

Scan the full history of every repository, not just the current branch. A key deleted in a later commit is still in the history.

Step 3: Rotate anything you find

Treat every discovered key as compromised. Deactivate it, check CloudTrail for its use, then delete it.

Step 4: Replace keys with roles

• Applications on AWS: use IAM roles for EC2, ECS task roles, EKS pod identity or Lambda execution roles.
• Developers: sign in through IAM Identity Center and use short-lived credentials from the CLI.
• CI/CD: use OIDC federation from GitHub Actions or other pipelines to assume a role, with no stored secrets.
• Third-party integrations: cross-account roles with an external ID instead of access keys.

Step 5: Put guard rails in place

• Use IAM Access Analyzer unused access findings to identify stale keys.
• Consider an SCP that restricts creating IAM user access keys except for approved accounts.
• Alert on access key creation.

Verify

Your target state is zero IAM user access keys in production accounts. Track the count monthly.