Possible AWS credential exposure in Lambda environment variables

Description

Hardcoding long-lived AWS credentials in Lambda environment variables can expose them through templates, deployment history or access to function configuration. Verify whether a value is an actual secret; its appearance alone does not establish a valid key. AWS API calls can normally use temporary credentials from the execution role.

Potential impact

If an actual access key ID and secret key are disclosed together, their permitted operations may be abused. Impact depends on attached policies and other access controls.

Remediation

Remove actual credentials and use an execution role with only the permissions the function needs. Retrieve other systems’ secrets from an appropriate secret store with restricted access.
Replace dependent credentials, then revoke and rotate exposed keys. Removing a value from the template does not erase copies in repository or deployment history.

Examples

The long foo string is a public AWS documentation example secret key, not an actual credential. Supply the real code bucket, object key and execution-role ARN, and verify that the code supports the specified runtime.

Before

yaml

Parameters:
  FunctionCodeBucket:
    Type: String
  FunctionCodeKey:
    Type: String
  ExecutionRoleArn:
    Type: String
Resources:
  LambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      Handler: index.handler
      Role: !Ref ExecutionRoleArn
      Environment:
        Variables:
          foo: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
          databaseName: lambdadb
          databaseUser: admin
      Code:
        S3Bucket: !Ref FunctionCodeBucket
        S3Key: !Ref FunctionCodeKey
      Runtime: nodejs22.x

This illustrates putting a credential value directly in configuration. Do not replace the example string with a real key and deploy it.

After