Lambda and SOC 2

AWS Lambda functions are increasingly common in startup architectures, but they introduce specific SOC 2 risks that are easy to overlook. Lambda's serverless nature can create IAM permission creep, unauthenticated HTTP endpoints, and end-of-life runtime versions — all of which auditors flag.

SecureSpect runs three Lambda-specific SOC 2 checks:

aws.lambda.function_url_auth — CC6.1
Verifies Lambda function URLs require authentication (AuthType=AWS_IAM)
rather than being open to unauthenticated requests (AuthType=NONE).
aws.lambda.no_wildcard_iam — CC6.1
Checks that Lambda execution roles do not have wildcard (*) actions
in their IAM policies — e.g., s3:* or lambda:*.
aws.lambda.runtime_version — CC7.1 (vulnerability management)
Flags functions running on deprecated runtimes (Python 3.7, Node.js 14, etc.)

Lambda Function URL Authentication

Lambda function URLs allow you to invoke a Lambda function via HTTPS without API Gateway. The risk: if AuthType=NONE, the function is publicly accessible to anyone with the URL.

Check your function URL configurations:

# List all functions with Function URLs
aws lambda list-function-url-configs --function-name your-function-name
# If AuthType is NONE on a production function, update it:
aws lambda update-function-url-config   --function-name your-function-name   --auth-type AWS_IAM

For functions that genuinely need public access (a webhook receiver, for example), use API Gateway with API key authentication or a custom authorizer — not a bare function URL with no auth.

Lambda IAM Permission Scope

Lambda functions run with IAM execution roles. The principle of least privilege requires that each function's role grants only the permissions that function actually needs. Wildcard permissions are a SOC 2 CC6.1 finding.

Common violation:

// BAD — do not use
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

Correct approach:

// GOOD — specific actions on specific resources
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::your-bucket-name/*"
}

To audit your Lambda function roles:

# Get the execution role for a function
role_arn=$(aws lambda get-function-configuration --function-name your-function --query 'Role' --output text)
role_name=$(echo $role_arn | cut -d/ -f2)
# List attached policies
aws iam list-attached-role-policies --role-name $role_name
# Get inline policies
aws iam list-role-policies --role-name $role_name

Lambda Runtime Currency

AWS deprecates Lambda runtimes on a rolling schedule. Running deprecated runtimes is a CC7.1 vulnerability management finding because deprecated runtimes don't receive security patches.

As of 2026, deprecated runtimes include Python 3.7, Python 3.8, Node.js 12, Node.js 14, Node.js 16, Ruby 2.7, and Java 8. Check your functions:

# List all functions and their runtimes
aws lambda list-functions   --query 'Functions[*].{Name:FunctionName,Runtime:Runtime}'   --output table

Migrate deprecated runtimes to current versions. For Python, 3.12 is the current LTS target. For Node.js, 20.x or 22.x.

Lambda-Specific SOC 2 Findings

The most common Lambda audit findings:

Function URLs with no authentication on what was intended as an internal tool

Overly broad IAM roles created quickly and never audited

Deprecated runtimes — teams forget to update Lambda runtimes when updating application code

Secrets in environment variables — database passwords or API keys passed as Lambda environment variables instead of retrieved from Secrets Manager at runtime

No function-level logging — Lambda automatically logs to CloudWatch, but teams sometimes disable this

FAQ

Does every Lambda function need to be included in SOC 2 scope? Only Lambda functions in your production environment that process or store in-scope data. Development/test functions are typically out of scope.

Can we use AWS Lambda Power Tuning for performance and still satisfy SOC 2? Yes — performance optimization doesn't conflict with SOC 2 requirements.

What about Lambda@Edge? Lambda@Edge functions run in us-east-1 and replicate globally. Apply the same controls: authentication, least-privilege IAM, current runtime.