# Ensure there are no secrets in Lambda function code

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292187776612-ensure-there-are-no-secrets-in-lambda-function-code
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that the code of every AWS Lambda function does not contain hardcoded secrets such as API keys, passwords, access tokens, private keys or database connection strings. All files in the function's deployment package are scanned, and any potential secret is reported with its file name and line number. Only functions deployed as zip packages are scanned; container image functions and layers are not.

**Rationale**

Secrets written into function code can be read by anyone who can download the deployment package, view the source repository or access build artifacts. Attackers can reuse them to access databases, third-party APIs or other cloud resources, and hardcoded secrets are hard to rotate. Storing secrets in AWS Secrets Manager or AWS Systems Manager Parameter Store and retrieving them at runtime with a least-privilege execution role avoids these risks.

**Impact**

-   Removes credentials from the deployment package and source code
    
-   Allows secrets to be rotated centrally without redeploying the function
    
-   The function code must be changed to read the secret at runtime, which adds a call to Secrets Manager or Parameter Store and may require caching to limit latency and cost
    
-   Any secret found in the code should be treated as exposed and rotated
    

**Default Value**

Lambda does not scan or block secrets in function code. Whether a function contains hardcoded secrets depends entirely on how its code was written.

**Pre-Requisites**

-   IAM permissions: lambda:ListFunctions, lambda:GetFunction, lambda:UpdateFunctionCode, secretsmanager:CreateSecret, iam:PutRolePolicy and iam:GetRole
    
-   Access to the function's source code and deployment process
    
-   Agreement with the owner of each exposed credential to rotate it
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the AWS Lambda console and select **Functions**.
    
3.  Select a function and open the **Code** tab.
    
4.  Review the source files for hardcoded API keys, passwords, tokens, private keys or connection strings. For larger packages, choose **Download** and scan the files with a secret scanning tool.
    
5.  Repeat for each function in each region in use.
    
6.  If any secret is found, follow the implementation steps.
    

**CLI:**

List the functions and their package type:

aws lambda list-functions --region <REGION> --query "Functions\[\].\[FunctionName,PackageType,Runtime\]" --output table

Get the temporary download link of a function's deployment package, then download it and scan its files with a secret scanning tool:

aws lambda get-function --region <REGION> --function-name <FUNCTION\_NAME> --query "Code.Location" --output text

A function fails if any file in its deployment package contains a value that looks like a secret. Only functions deployed as .zip packages are evaluated; container image functions are not.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the AWS Secrets Manager console and choose **Store a new secret**.
    
3.  Store the hardcoded value as a secret and note the secret name or ARN.
    
4.  Open the IAM console, select **Roles** and open the function's execution role.
    
5.  Add a policy that allows secretsmanager:GetSecretValue on that secret only (and kms:Decrypt on its key, if a customer managed key is used).
    
6.  Change the function code to remove the hardcoded value and read the secret at runtime with the AWS SDK (GetSecretValue), or with the AWS Parameters and Secrets Lambda Extension.
    
7.  Deploy the updated function code and test the function.
    
8.  Rotate the exposed credential at its source, because it must be considered compromised.
    
9.  Repeat for each affected function in each region in use.
    

**Backout Plan**

Before making changes, keep a copy of the current deployment package (download it from the **Code** tab or with the Test Plan command).

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the AWS Lambda console and select the function.
    
3.  In the **Code** tab, choose **Upload from** and upload the previous deployment package, or publish the previous function version through your deployment pipeline.
    
4.  Test the function.
    

Note: rolling back puts the hardcoded secret back into the function code. If the credential has already been rotated, the old value will no longer work, so update the code to use the secret store instead.

**Reference**

-   [https://docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html](https://docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html)
    
-   [https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets\_lambda.html](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html)
    
-   [https://aws.amazon.com/blogs/security/how-to-securely-provide-database-credentials-to-lambda-functions-by-using-aws-secrets-manager/](https://aws.amazon.com/blogs/security/how-to-securely-provide-database-credentials-to-lambda-functions-by-using-aws-secrets-manager/)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/lambda/get-function.html](https://docs.aws.amazon.com/cli/latest/reference/lambda/get-function.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.