Performing Serverless Function Security Review
When to Use
- When auditing serverless applications before production deployment
- When investigating potential data exposure through function environment variables or logs
- When assessing the blast radius of a compromised serverless function execution role
- When compliance reviews require documentation of serverless security controls
- When building secure-by-default templates for serverless deployments
Do not use for container or VM security assessments (use container scanning tools), for API security testing (use DAST tools on the API Gateway layer), or for real-time serverless threat detection (use AWS Lambda Extensions with security agents).
Prerequisites
- AWS CLI, Azure CLI, and gcloud CLI configured with appropriate permissions
- Access to read function configurations, policies, and execution roles
- Prowler or Checkov for automated serverless security scanning
- SAM CLI or Serverless Framework for local function analysis
- CloudTrail, Azure Monitor, or Cloud Audit Logs enabled for function invocation monitoring
Workflow
Step 1: Enumerate All Serverless Functions and Configurations
List all functions across cloud providers with their runtime, memory, timeout, and network settings.
aws lambda list-functions \
--query 'Functions[*].[FunctionName,Runtime,MemorySize,Timeout,Role,VpcConfig.VpcId,Layers[*].Arn]' \
--output table
aws lambda list-functions \
--query 'Functions[?Runtime==`python3.7` || Runtime==`nodejs14.x` || Runtime==`dotnetcore3.1`].[FunctionName,Runtime]' \
--output table
az functionapp list \
--query "[].{Name:name, Runtime:siteConfig.linuxFxVersion, ResourceGroup:resourceGroup, HttpsOnly:httpsOnly}" \
-o table
gcloud functions list \
--format="table(name, runtime, status, httpsTrigger.url, serviceAccountEmail, vpcConnector)"
Step 2: Audit Execution Role Permissions
Review IAM roles attached to functions for overly permissive policies.
for func in $(aws lambda list-functions --query 'Functions[*].FunctionName' --output text); do
role_arn=$(aws lambda get-function-configuration --function-name "$func" --query 'Role' --output text)
role_name=$(echo "$role_arn" | awk -F'/' '{print $NF}')
echo "=== $func -> $role_name ==="
aws iam list-attached-role-policies --role-name "$role_name" \
--query 'AttachedPolicies[*].[PolicyName,PolicyArn]' --output table
for policy_arn in $(aws iam list-attached-role-policies --role-name "$role_name" --query 'AttachedPolicies[*].PolicyArn' --output text); do
version=$(aws iam get-policy --policy-arn "$policy_arn" --query 'Policy.DefaultVersionId' --output text)
aws iam get-policy-version --policy-arn "$policy_arn" --version-id "$version" \
--query 'PolicyVersion.Document' --output json | python3 -c "
import json, sys
doc = json.load(sys.stdin)
for stmt in doc.get('Statement', []):
actions = stmt.get('Action', [])
if isinstance(actions, str): actions = [actions]
resources = stmt.get('Resource', [])
if isinstance(resources, str): resources = [resources]
if '*' in actions or any(a.endswith(':*') for a in actions):
print(f' WARNING: {stmt[\"Effect\"]} {actions} on {resources}')
" 2>/dev/null
done
done
Step 3: Check Environment Variables for Secrets
Scan function environment variables for hardcoded credentials, API keys, and database connection strings.
for func in $(aws lambda list-functions --query 'Functions[*].FunctionName' --output text); do
envvars=$(aws lambda get-function-configuration --function-name "$func" \
--query 'Environment.Variables' --output json 2>/dev/null)
if [ "$envvars" != "null" ] && [ -n "$envvars" ]; then
echo "=== $func ==="
echo "$envvars" | python3 -c "
import json, sys, re
vars = json.load(sys.stdin)
sensitive_patterns = [
r'(?i)(password|secret|key|token|credential|api.?key)',
r'(?i)(aws.?access|aws.?secret)',
r'(?i)(database.?url|connection.?string|db.?pass)',
r'AKIA[0-9A-Z]{16}'
]
for key, value in vars.items():
for pattern in sensitive_patterns:
if re.search(pattern, key) or re.search(pattern, str(value)):
masked = value[:4] + '****' + value[-4:] if len(value) > 8 else '****'
print(f' SENSITIVE: {key} = {masked}')
break
"
fi
done
for app in $(az functionapp list --query "[].name" -o tsv); do
rg=$(az functionapp show --name "$app" --query "resourceGroup" -o tsv)
echo "=== $app ==="
az functionapp config appsettings list \
--name "$app" --resource-group "$rg" \
--query "[?contains(name,'KEY') || contains(name,'SECRET') || contains(name,'PASSWORD')].{Name:name}" \
-o table 2>/dev/null
Step 4: Review Function Triggers and Access Controls
Verify that function triggers have appropriate authentication and authorization.
aws lambda list-function-url-configs \
--function-name FUNCTION_NAME \
--query 'FunctionUrlConfigs[*].[FunctionUrl,AuthType,Cors]' --output table
for func in $(aws lambda list-functions --query 'Functions[*].FunctionName' --output text); do
policy=$(aws lambda get-policy --function-name "$func" --query 'Policy' --output text 2>/dev/null)
if [ -n "$policy" ]; then
echo "$policy" | python3 -c "
import json, sys
doc = json.loads(sys.stdin.read())
for stmt in doc.get('Statement', []):
principal = stmt.get('Principal', {})
if principal == '*' or principal == {'AWS': '*'}:
print(f'WARNING: $func has public invoke policy: {stmt.get(\"Sid\", \"unnamed\")}')" 2>/dev/null
fi
done
gcloud functions list --format=json | python3 -c "
import json, sys
functions = json.load(sys.stdin)
for func in functions:
name = func.get('name', '').split('/')[-1]
trigger = func.get('httpsTrigger', {})
if trigger and func.get('ingressSettings') == 'ALLOW_ALL':
print(f'WARNING: {name} allows all ingress traffic')
"
Step 5: Analyze Function Code for Security Vulnerabilities
Review function code for common serverless security issues.
aws lambda get-function --function-name FUNCTION_NAME \
--query 'Code.Location' --output text | xargs curl -o function.zip
unzip function.zip -d function-code/
pip install bandit
bandit -r function-code/ -f json -o bandit-results.json
npm install -g eslint @microsoft/eslint-plugin-sdl
eslint --ext .js function-code/
grep -rn "os.system\|subprocess\|eval(\|exec(" function-code/ || echo "No obvious injection patterns"
grep -rn "pickle.loads\|yaml.load\b" function-code/ || echo "No deserialization risks"
Step 6: Run Automated Serverless Security Scanning
Execute Checkov and Prowler for automated compliance checks on serverless resources.
checkov -d ./serverless-project/ \
--framework serverless \
--output json > checkov-serverless.json
prowler aws \
--checks lambda_function_no_secrets_in_variables \
lambda_function_url_auth_type \
lambda_function_using_supported_runtimes \
lambda_function_not_publicly_accessible \
-M json-ocsf \
-o ./prowler-lambda/
Key Concepts
| Term | Definition |
|---|
| Execution Role | IAM role assumed by a serverless function during execution that defines what AWS/cloud resources the function can access |
| Event Injection | Serverless-specific attack where untrusted data in the event trigger payload is used unsafely in function logic |
| Function URL | Direct HTTP(S) endpoint for invoking Lambda functions without API Gateway, which may be configured without authentication |
| Cold Start | Initial function execution that includes container provisioning, during which security agents and extensions must initialize |
| Resource-Based Policy | Policy attached to the function itself that defines who can invoke it, separate from the execution role |
| Secrets Manager Integration | Pattern of retrieving sensitive configuration from a secrets management service rather than storing in environment variables |
Tools & Systems
- AWS Lambda: Primary serverless compute platform with execution roles, layers, and resource policies
- Checkov: Static analysis tool for infrastructure-as-code with serverless-specific security policies
- Prowler: Cloud security tool with Lambda-specific checks for permissions, public access, and runtime versions
- Bandit: Python static analysis tool for detecting security issues in function source code
- OWASP Serverless Top 10: Security risk framework specific to serverless architectures
Common Scenarios
Scenario: Lambda Function with Admin Role Leaking Secrets via Environment Variables
Context: A security review discovers a Lambda function with AdministratorAccess execution role and database credentials stored in plaintext environment variables visible in CloudWatch logs.
Approach:
- Enumerate the function's execution role and discover
AdministratorAccess managed policy
- Check environment variables and find
DB_PASSWORD, API_KEY, and STRIPE_SECRET_KEY in plaintext
- Review CloudWatch logs and find credentials printed in debug log statements
- Create a scoped IAM policy granting only the specific DynamoDB and S3 actions needed
- Migrate secrets to AWS Secrets Manager and update function to retrieve at runtime
- Remove debug logging that outputs sensitive data
- Rotate all exposed credentials and enable Lambda function encryption with KMS
Pitfalls: Changing a function's execution role can break it if the new role is too restrictive. Test in a staging environment first. Environment variable changes trigger a new function version, so ensure aliases and triggers are updated. Secrets Manager calls add latency; cache secrets within the execution context to avoid per-invocation lookups.
Output Format
Serverless Function Security Review
=======================================
Account: 123456789012
Functions Reviewed: 34
Review Date: 2026-02-23
CRITICAL FINDINGS:
[SRVL-001] Overly Permissive Execution Role
Function: payment-processor
Role: AdministratorAccess (full AWS access)
Required Permissions: DynamoDB:PutItem, S3:GetObject (2 actions)
Remediation: Create scoped policy with only required permissions
[SRVL-002] Secrets in Environment Variables
Function: payment-processor
Variables: DB_PASSWORD, STRIPE_SECRET_KEY, API_KEY
Risk: Visible in console, API, and CloudWatch logs
Remediation: Migrate to Secrets Manager, remove from env vars
SUMMARY:
Functions with admin roles: 3 / 34
Functions with secrets in env vars: 8 / 34
Functions with deprecated runtimes: 5 / 34
Functions with public access: 2 / 34
Functions without VPC: 28 / 34
Functions with wildcard permissions: 12 / 34
