c2.21 Keep secrets out of code

Do not hardcode secrets

A secret in code can be read by anyone with access to the repository, is easily leaked to public repositories, and is hard to rotate. If the hardcoded secret is an access key, prefer temporary credentials via roles instead.

Fetch long-lived secrets at runtime

When your code needs a genuine long-lived secret (a database password, a third-party API key), store it in AWS Secrets Manager and retrieve it at runtime. Grant the workload permission to read the secret through its IAM role (instance profile, Lambda/ECS execution role), so no credential is embedded in the code. Secrets Manager can rotate supported secrets automatically — see the best practices.

Catch secrets before they ship

Scan code for committed secrets with tools such as git-secrets, and integrate secret scanning into your pipeline so a detected secret blocks promotion. Amazon Q Developer also flags secrets as code is written.

Fetch at runtime, scan before commit

Retrieve the secret at runtime instead of hardcoding it:

aws secretsmanager get-secret-value \
  --secret-id prod/db/password \
  --query SecretString --output text

Add a repository scan so a committed secret blocks the pipeline:

git secrets --install
git secrets --register-aws
git secrets --scan